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Módszertanok kora 


Tervezési minták a fejlesztésben 


Sokan úgy gondolják, hogy az elemi programozási ismeretek (ciklus, válto- 
zó stb.) birtokában a szoftverkészítés nem ördöngösség. Csak leírjuk, amit 
akarunk, és működik. Ha mégsem, hát teszünk bele néhány if-et a kivéte- 
les esetek lekezelésére. Ezt a fejlesztési , módszertant" buherálásnak hívják, 
ami garantáltan hibás programokat eredményez. Kell ez nekünk? 


Kellhet. Jó zsíros karbantartási szerződéseket lehet kötni a buherált programokra. De gon- 
doljuk végig egy pillanatra a másik utat: mi lenne, ha szoftverfejlesztéseink során nem egyik 
zsákutcából a másikba, egyik if-ből a másikba támolyognánk? Ha nem írnánk meg olyan kó- 
dot, amit már mások megírtak? Ha felhasználnánk jeles elődeink eredményeit? 

Egy éve egy utazás kapcsán találkoztam két autótervező mérnökkel. A fiatalok egy vidéki 
cégnél dolgoztak, német megrendelésre. A beszélgetés fonalát régi rögeszmémmel indítot- 
tam, nevezetesen hogy a szoftverek milyen vackok, bezzeg az autógyártás! S a minőség, a 
precizitás csúcsa, a német autó. Hogy meg van tervezve, mekkora csoda egy-egy autó! S mi- 
lyen felemelő érzés lehet alkotó módon hozzájárulni egy remekműhöz! 

Hihetetlen választ kaptam! Még hogy az autók jól meg lennének tervezve? Mit gondolok én, 
miért nem próbálható ki a szakmai seregszemléken a prototípus? Mert a négyhengeres mo- 
torból egy fél hengernyit le kellett vágni flexszel, hogy beférjen a karosszériába! 

Eh, mondom, az szörnyű vakvéletlen. Erre sorolják, hogy melyik autóban fut derékszögben 
megtörve az ékszíj, mert teletervezték alkatrésszel a futási útvonalát, így kerülőúton kell ha- 
ladnia. Egy kocsit teljesen újra kellett tervezni, mert — szintén tervezési baki miatt — az olaj- 
szint pálcának nem maradt helye a kihúzásra: odakerült egy másik alkatrész. Mire az olaj- 
pálca végre kiszabadult, az egész elrendezés felborult. Vagy gondoljunk a visszahívott ko- 
csikra, melyek egy piciri alkatrész hibás tervezése folytán borulékonnyá váltak. Vagy arra az 
olasz autóra, amiben csak a motor kiszerelése árán lehet izzót cserélni satöbbi. S hogy 
mindez miért? Mert a tervezést alávetik mind a dögös dizájnnak, mind az időnek. 

Először a karosszéria készül el, művész urak tervezik. Ebből előáll egy drótváz. A lényeg 
(motor, akku stb.) tervezőinek az a feladata, hogy a látványtervezők által megálmodott drót- 
vázon belül maradjanak, mert ha nem, akkor zaporozsec születik (kívül lesz a térképtartó). 
A hely és az idő iszonyú kevés, ezért egyszerre mintegy négyszázan esnek neki a motortér 
elfoglalásának, s aki fürgébb, szabadabban tervezi be a saját alkatrészét a térbe. Aki lassab- 
ban ocsúdik, sarokba szorul: teheti az alkatrészét a motorblokk alá (ekkor beszélünk újrater- 
vezett modellről :-). Bukta akkor van, ha a lefoglalt területeket nem publikálják a közös adat- 
bázisban, magyarul nem csekkelnek in. Minden tervező kötelessége, hogy a munkanap vé- 
gén becsekkolja a közösbe, mit alkotott, milyen erőforrásokat pusztított. Ha elmulasztja, le- 
het, hogy később már nem tudja betenni a közösbe, mert nem fér. 

Ennyiből is látható, hogy az autógyártás kísértetiesen hasonlít a szoftvergyártásra. Modulok, 
check in a nap végén, s másnap minden kezdődik elölről. Egy igen lényeges különbséget 
azonban rögön megemlítenék: míg általában az autók tervezését hozzáértő mérnökök vég- 
zik, addig sok szoftvert nem tervez meg senki. Csak írjuk, írjuk, írjuk. A következő különb- 
ség az alkatrészek felhasználásában mutatkozik: egy-egy autógyár a költségek csökkentése 
érdekében bizonyos alkatrészeket olyan jól megtervez, hogy változtatás nélkül felhasznál- 
hatók a különböző modellekben. És ne csak iciri-piciri alátétekre gondoljunk: egy-egy jól 
tervezett alváz elcipel 3-4 modellt! Évekig nem nyúlnak hozzá. Minek, hisz bizonyítottan jó! 


OOP 


Vessük ezt össze az objektumorientált programozással: elvileg adott volna az objektumok 
újrahasznosításának lehetősége, ha azt az átkozott objektumot megtervezték volna. De mi- 
vel ez nem történt meg, minden egyes felhasználáskor meg kell a kódot fűszerezni egy ke- 
vés if-fel. (És máris kész a 4.2.45.132 verzió, valamint a DLL Hell.) Mi lenne, ha az alváza- 
kat is csak if-ek árán lehetne újrahasznosítani (még 1-2 furat ide, egy fülecskét hegesztünk 
oda...) 

. . folytatás a 4. oldalon! 
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Desiun Patterns bevezetés 


Szoftvertervezési kérdésekről beszélgetve előbb-utóbb beleütközünk a Design 
Patterns-ekbe. A követelmények feltérképezése után egy nagy szakadék tátong az 
emberi nyelven leírt követelmények és az azt megvalósító kód között. A szakadé- 

kot a tervezési folyamatnak kell(ene) áthidalnia. Az építészek vagy a gépészek éve- 
kig tanulnak rendszereket tervezni. Nem kellene ennek így lenni az informatikában 
is? Elő hát a Tervezési mintákkal, elő a Design Patternekkel! 
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z Avagy ki látott már sikeres, határidőre befejezett, költségkere- 
e ten belül maradó szoftverfejlesztési projectet? 


Ha egy fejlesztőcsapat fejébe veszi, hogy következő projektjét már nem bukja el, érdemes 
megismerkednie az MSF keretrendszerrel. Ez ugyanis nem mást tartalmaz, mint a világ leg- 


nagyobb szoftvergyárában korábban előfordult bukásokból levont tanulságokat, és a ,kihívá- 
A sok" elkerülésének lehetőségeit. 


Portál Paraldigmal 
IN. rész — the X files 





az XML-t és az XSLT-t. Arról azonban kevés szó esett, hogy pontosan milyen szerepet 


is kapnak az X-fájlok egy portál életében, illetve hogyan kell őket alkalmazni egy többrétegű 
korszerű portálmegoldás fejlesztése közben. Az igazság ezúttal ideát van. SES 
m—]) 


Sorozatunk első két részében sokat emlegettük a különféle x-szel kezdődő fájlokat, elsősorban 
Tu] 
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as Petri-hálók modellezése és analízise 
A korábbiakban bemutattam a Petri-hálók működését. Most egy kicsit gyakorlatia- 
sabb oldaláról igyekszem megközelíteni a dolgot, így egy olyan eszközt mutatok 
rigai be, amely modellezési- és különböző analíziscélokra egyaránt alkalmas. 
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Internet Information Services 5.0 

NH. rész: A Windows 2003 Server 
webkiszolgálójának újdonságai 

Az előző részben megismertük az IIS 6.0 webkiszolgálójának új belső si 


felépítését. Most tovább ismerkedünk a webkiszolgálóval és terítékre kerül Descípborr . IIS inciudes Web, FTP. SMTP. and NNTP support, along with support 
4 öz ő for FrontPage Server Extensions and Active Server Pages (ASP). 
az FTP szolgáltatás is. 


v TÁ Aopácaton Server Console 
CI 8 ASP.NET 00MB 
71 GB Erable network COM: e access 










Total dsk space regviredt 0048 Detalt. 


Space avalable on disk ———25541MB 
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Szinte minden TCP/IP hálózat rendelkezik DHCP szolgáltatással. Ez az alkalmazás 
háttérbe húzódik, a felhasználók sohasem találkoznak vele, és ha jól működik, a 
rendszergazdák is csak hébe-hóba vetnek rá pillantást. Itt is érvényes az ókori böl- 
csesség: ami nem látható, az fontosabb, mint ami látható. 


Brightstor ARLserve v9 for Iindors 
Foglalt állományok és alkalmazásszerverek mentése 


Az adatmentés teljességének feltétele a mentendő adatok állományszintű vál- 
tozatlansága. Ez a feltétel feloldandó érdekütközéshez vezet a gazdaalkalma- 
zás és mentőmegoldás között. 


j 


DHCP Client 


A DHLP rejtett szépségei 


I. rész 


éeszazzinnzszaniijó- 
IP lease reguest 


Merre 
IP lease offers 


—G———— re 
IP lease selection 


edfjez— 


IP lease acknowledgment 


Parancssori környezet és eszközök 
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DHCP Servers 
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Halál a GUI-ra 





Llommunicare necesse est! 


Használjuk erre a legmegfelelőbb eszközt! 


A Microsoft Exchange a maga 110 millió felhasználójával magasan nap- 
jaink vezető üzenetkezelő és csoportmunka platformja. És hamarosan itt az 
Exchange 2003 (Titanium) az új verzió! Bátorfi Zsolt bevezető cikke után 
vizsgáljuk meg közelebbről, hogy mit rejtenek a csillogó korongok. Áttér- 
jünk? Várjunk? Jobb lesz? Próbáljuk ki! Nézzük meg a gyakorlatban, hogy 
mi lakik a hangzatos név mögött! 
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Sok UNIX-os szakember nézte le a Windows kiszolgálókat, mert csak grafikus 
környezetből lehetett üzemeltetni őket. Megpróbálom bebizonyítani, hogy az 
új generációs Windows kiszolgálókat immáron kizárólag parancssorból, ma- 
nuálisan (és automatizáltan is) lehet mindenre kiterjedően adminisztrálni, kon- 
figurálni és felügyelni. A cikkben — ismétlésképpen — némi DOS-ismeretet is 
megemlítek azon fiatalok kedvéért, akik akkor még nem éltek... 
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A .Net és a Tablet PL 


Miért fontos, hogy a Tablet PC a .Net keretrendszerre épül és a felhasználó számára 
milyen haszonnal jár a beépített .NET infrastruktúra? Hogyan illeszkedik a táblás mo- 
dell a .NET stratégiába? A Microsoft PressPass kérdéseire Vic Gundotra, a Platform 
Strategy igazgatója és Alex Gounares, a Tablet PC vezető tervezője válaszolt. 








- Tervezési minták a fejlesztésben / Köszöntő 


Módszertanok kora 


. . folytatás az 1. oldalról 


És vajon mi lenne, ha az objektumorientált progra- 
mozást arra (is) használnánk, amire való? Ha jól 
megtervezett, módosítás nélkül újrahasznosítható 
objektumok kerülnének ki az objektumgyárakból? Megmon- 
dom: stabilabb kód, kevesebb biztonsági rés, kevesebb mun- 
ka. Akkor miért nem így fejlesztünk? Mert senki sem tudja, 
mi fán teremnek a tervezési minták. (Egy éve még én sem 
tudtam...) ú 


Design Patterns 


A tervezési minták, vagy más néven sablonok arra szolgál- 
nak, hogy ha lehet választani, inkább ezerszer felhasznált, 
rongyosra tesztelt megoldásokat keressünk ahelyett, hogy ne- 
kiállnánk a spanyol viasz feltalálásának. Autós példával élve: 
ha belülről állítható visszapillantó tükörre van szükség a ter- 
vezés folyamán, akkor vegyünk le a polcról egy bevált tervet 
ahelyett, hogy elkezdenénk gondolkozni azon, hogyan lesz 
a kvarchomokból üveg, az üvegből tükör stb. A pattern szó 
mintát jelent, melyet összekapcsolhatunk a mintafelismerés- 
sel. Hiába vannak ugyanis kiváló sablonjaink, ha adott hely- 
zetben nem ismerjük fel, hogy melyik illene a problémára. 


Az objektumorientált programozást elvileg abból a célból (is) 
alkották nekünk, hogy kész objektumokból építkezhessünk. 
A napi valóság azonban azt mutatja, hogy szinte nincs olyan 
objektum, melyet érintetlenül újrafelhasználnák készítőik. 
Egy kevés IF mindig kell bele! Különösen sok IF megy bele, 
ha olyanra sikeredett, amely csak egy adott helyzetben hasz- 
nálható. A világ változik, az objektumot (tükröt) legközelebb 
mikrobuszra kell felszerelni. Ennek a követelménynek csak a 
jól megtervezett alkatrészek, objektumok felelnek meg vál- 
toztatás nélkül. 


A spanyol viasz 


Az egyik leggyakoribb jelenség, amikor a programozó nem 
ismeri fel, hogy olyan problémán küzd, amit előtte ezermil- 
lióan megoldottak már. Ki jól, ki rosszul, de az ezermillió 
közt legalább száz jó megoldás van. Hősünk azonban fabri- 
kál egy ezermillió-egyedik megoldást, amely alig hibás, és 
csak négy teljes napja ment rá. Ilyen az a tipikus probléma, 
hogy egy alkalmazásból / objektumból / végrehajtási szálból 
/ tep csatornából / akármiből egyszerre, egyidejűleg csak 
egyetlenegy legyen a memóriában / fusson / legyen nyitva / 
akármi. Ez a feladat oly tipikus, hogy külön tervezési sablon- 
ja van: ez a singleton. 


A Singleton 


Annak biztosítása, hogy csak egyetlen bal külső visszapillan- 
tónk legyen, viszonylag egyszerű: a legelső felszerelése után 
elfogynak a furatok, nincs hova szerelni a másodikat. Azon- 
ban a Windowson nincsenek furatok, ha egyetlenegy 
EXCHSRVR.EXE futtatása a kívánatos, ezt magának az adott 
objektumnak kell elintéznie: mintha a visszapillantó tükör 
maga szabályozná, hogy belőle csak egy lehet. Bizonyos 


programozási nyelvek és keretrendszerek nem sok le- 
hetőséggel szolgálnak a probléma megoldására, barkácsolás- 
ra kényszerülünk: jönnek az IF-ek és a globális változók. A 
Ct nyelv viszont lehetővé teszi, hogy az objektum definíció- 
ja, osztálya rendelkezhessen az objektum létrehozásáról, 
azaz a visszapillantó képes megszámolni saját példányait. 
Az alábbi kódrészlet ezt a lehetőséget szemlélteti: 





Nincs globális számláló, mi több, a hívó alkalmazásnak nem 
is kell tudnia, hogy az objektum singletonként tengeti életét. 
Mi csak meghívjuk, és ő gondoskodik saját kényelméről! A 
lényeg hat sorban elfért, a többi zárójel, soremelés stb. a 
könnyebb olvashatóság végett. Ezek után nem kell más, mint 
hogy a programozó mindig felismerje, hogy egy singleton 
problémával áll szemben, és levegye a polcról ezt a sablont. 
Nem bírom abbahagyni e minta dicséretét: borzasztó egy- 
szerűen átalakítható tetszőleges számú példány engedélye- 
zésére. (A Network Load Balancing is egy singleton: egy 
ponton férünk hozzá, és ő eldönti, hogy hány példányt en- 
ged, és mi melyikkel kommunikálunk!). Ha egy alkalmazás 
azt kérdi, hogy hány ezmegazt (kockát, végrehajtási szálat, 
párhuzamos szólamot, akármit) szeretnénk, akkor kibővített 
singletonnal állunk szemben. 

További csinos tervezési minták is léteznek, ezekről szól a 
következő cikk. Végül hadd hívjam fel a figyelmet egy másik 
módszertanra, a Microsoft Solutions Frameworkre is, melyről 
a kilencedik oldalon kezdődő cikk közöl részleteket. 


Fóti Marcell 

marcellfonetacademia.net 
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Design Patterns bevezetés 


Szoftvertervezési kérdésekről beszélgetve előbb-utóbb beleütközünk a Design 


te 


Patterns-ekbe. A követelmények feltérképezése után egy nagy szakadék tátong az 
emberi nyelven leírt követelmények és az azt megvalósító kód között. A szakadékot 
a tervezési folyamatnak kell(ene) áthidalnia. Az építészek vagy a gépészek évekig tanulnak rendszere- 
ket tervezni. Nem kellene ennek így lenni az informatikában is? Elő hát a Tervezési mintákkal, elő a 


Design Patternekkel! 


Történelem 


A Patternek fogalma Christopher Alexander építészhez kap- 
csolható. Építészhez? Bizony, bizony. Ha belegondolunk, az 
építészet pont egy olyan szakma, ahol tervezni kell, apró alko- 
tóelemekből kell összerakni egy lehetőleg szervesen egyként 
viselkedő alkotást, például az épületet. Mitől otthonos egy la- 
kás, és mitől idegen egy másik? Sándor elgondolkodott ezen, 
és rájött, hogy a profik ösztönükre hagyatkozva valamint a 
múltbéli tapasztalataik alapján jó terveket készítenek. Például 
minden terasz esetén megfogható 10-20 olyan alapvető tulaj- 
donság, amely ha szerepel a terasz tervében, az hangulatos, 
barátságos lesz. Misztérium? Mindjárt kiderül, nem. 

Felfigyelt arra, hogy bizonyos problémák újra és újra felbuk- 
kannak a tervezőmunka során, és ezekre mindig más, de jelle- 
gében mindig nagyon hasonló megoldást kellett adni. 

A folyamatot a probléma, környezet, megoldás hármassal jel- 
lemezte, ahol tulajdonképpen a környezeti feltételek és maga 
a probléma ismeretében leírt egy általánosan használható 
megoldást. Negyedszázada jelent meg könyve ,A Pattern 
Language: Towns, Buildings, Construction" címmel. Ebben 
250 tervet írt le, amelynek segítségével még a tapasztalatla- 
nabb tervezők is sokkal gyorsabban tudtak épületeket tervezni, 
ráadásul — és ez nagyon fontos — az elkészült tervek magukon 
hordozták a mintákban leírt tudást, így azok nagyobb valószí- 
nűséggel lettek szebbek, jobbak vagy használhatóbbak. 

Chris könyve elgondolkodtatta a szoftvertervezőket is, hisz a 
programtervezés folyama hasonló problémákat vet fel, mint az 
építészet. Kis részeket kell kidolgozni, majd abból összerakni 
egy teljes egészet. Először Smalltalk környezetben használták 
fel a patternek mentén vezetett gondolkodásmódot, amelyben 
dokumentumok, a megjelenítés és a felhasználói beavatkozás 
elválasztására megalkották a Model-Controller-View mintát. 
Aki ismeri az MFC-t, annak Document-View architektúra né- 
ven ismerős lehet ez. 

Aztán a 90-es évek elején elkezdett szerveződni egy csoport, 
amely később a Gang of Four (GoF), a négyek bandája nevet 
kapta. Tagjai: Erich Gamma, Richard Helm, Ralph Johnson és 
John Vlissides. 1995-re elkészült közös könyvük, melynek cí- 
me: Design Patterns, Elements of Reusable Object-Oriented 
Software (Addison-Wesley, 1995). Általában e könyv megjele- 
nését tekintik a szoftver DP-ek kiindulási idejének. A továb- 
biakban egyszerűen a GoF néven fogok rájuk hivatkozni, 
könyvükre pedig a DP könyvként. 


Mi az a Design Pattern? 
A legáltalánosabb definíció: 










megnevezet 28 újra 
bizonyos környezet é 


A szoftvertervezés egyik legnagyobb problémája, hogy nem al- 
goritmizálható, nagyon intuitív folyamat. Egy-egy problémára 
általában végtelen sok megoldás adható, csak éppen az egyik 
egyszerű lesz, a másik meg bonyolult. Az egyik hatékony, a 
másik csapnivalóan lassú. Az egyik könnyen módosítható, a 
másik egy nagy, összefüggő gubanc. 

Egy tapasztalt szoftvertervező már nem talál ki minden egyes 
problémára új megoldásokat, hanem vannak a fejében olyan 
megoldás-sablonok, amelyeket korábbi tervezési feladatokból 
szűrt le. A kezdő fejében — bármilyen okos is — még nincsenek 
azonnal alkalmazható megoldások, így neki is végig kell járni 
azt az utat, amit a tapasztalt kollégája már bejárt. 

Kivéve, ha ... valaki leírja, mi jár a fejében. Ha valaki precízen 
dokumentálja, hogy adott környezeti feltételek mellet találko- 
zott egy ilyen és ilyen tervezési problémával, és a sok megol- 
dás közül ez bizonyult a legjobbnak. Éles környezetben több- 
ször kipróbálta különböző feladatokra, és sikeresen tudta alkal- 
mazni rájuk. Tulajdonképpen ezt tette meg a GoF, ezekből 
születtek meg a könyvben leírt DP-k. 

Gyakorlati projektekben kielemezték nagyobb architektúrák 
részmegoldásait, és megfogalmazták, hogy adott típusú problé- 
mára milyen megoldást lehet adni. A megoldások általában 
nem triviálisak. Pont az a jó a DP-kben, hogy azáltal, hogy az 
első ötletnél valamivel bonyolultabb megoldást adnak egy 
problémára, a kapott eredmény jól bővíthető, könnyen módo- 
sítható, azaz könnyebben képes alkalmazkodni a megváltozott 
üzleti igényekhez. Aki már dolgozott valamilyen tényle- 
ges megrendelésen, tudja, hogy ez milyen fontos tényező 
egy munka sikere szempontjából. Alapvetően, életbevágóan 
fontos. 


Milyen előnyökkel járnak a DP-k? 


A DP-k számtalan ponton segíthetnek a tervezésben. Nézzük 
át a legfontosabbakat! 


A Lerövidíthetik a tervező betanulási idejét. A DP-ket 
olyan emberek írták, akik tényleg értenek a tervezés- 
hez. Nem kizárt, hogy valaki tud frappánsabb vagy 
valamilyen szempontból jobb megoldást szülni egy 
problémára mint a GoF, de általában érdemes megér- 
teni, hogyan gondolkodtak a szerzők, ha más miatt 
nem, hát azért, mert sokat lehet belőle tanulni. 

AA Lerövidíthetik a tervezés idejét. Ha valakinek már a 
fejében van néhány minta, és esetleg sikeresen alkal- 
mazta is őket valamilyen feladat megoldásában, 
előbb-utóbb azon kapja magát, egy tervezés során 
beugrik neki, hogy most, adott viszonyok között ide 
egy mondjuk Visitor patternre volna szükség. Az 
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UA 


így születő megoldások lehet, hogy valamivel 

összetettebbek lesznek, mintha saját kútfőből szül- 

tük volna meg őket (képzavar — a szerk.), de cseré- 
be szinte biztos, hogy sokkal jobban bővíthető és 
módosítható lesz a kapott architektúra. 

HA Szótárat ad a programozók kezébe. Amikor azt mon- 
dom autó, nem kell körbemagyaráznom, hogy egy 
olyan dobozról van szó, aminek négy kereke van, em- 
berek közlekednek vele, hanem mindenki tudja mire 
gondolok. Ez az absztrakció lényege. Az absztrakció a 
gondolkodás egy újabb szintje, ennek köszönhető, 
hogy (viszonylag) hatékonyan tudunk egymással kom- 
munikálni. 

Ha azt mondom olló, mindenki tudja mire gondolok. 
Ha azt mondom Observer DP, már sokkal kevesebben. 
Miért, mi a különbség a kettő között? Gyakorlatilag 
csak az, hogy az egyiket már ismerjük, mert annyiszor 
láttuk és megtapasztaltuk, a másikat pedig még nem. 
Amint valaki megismer egy fogalmat vagy tárgyat, 
azonnal él vele a kommunikációban, mert így sokkal 
tömörebben és hatékonyabban tudja kifejezni magát. 
Ezek után ha két DP-ket ismerő tervező beszélget egy- 
mással, nem kell nekik kilométeres mondatokkal min- 
dent körbemagyarázni, ha van egy egységes szótár, ami 
alapján mindketten tudják miről van szó. Emiatt na- 
gyon fontos, hogy minden egyes DP-nek van egy 
könnyen megjegyezhető neve, így az beépülhet a ter- 
vezők szótárába, megkönnyítve az írásos és a szóbeli 
kommunikációt. 

A A legtöbb DP leghosszabb része a Következmények 
(Conseguences) rész. Ebben nagyon alaposan kielem- 
zik a DP által a kiinduló problémára felvázolt megol- 
dás előnyeit-hátrányait, alkalmazhatóságát. E részekből 
rengeteg tervezési meggondolást lehet tanulni, megis- 
merni, hogyan gondolkodnak a profik, amit aztán mi is 
beépíthetünk a saját gondolkodásmódunkba. Azaz a 
DP-ket tanulmányozva olyan tervezési megfontolások- 
ra tehetünk szert, amelyeket talán évek alatt sem tud- 
nánk magunktól összeszedni. 


Vannak más patternek is, mint a GoF DP-k? 


A szakmában számtalan egyéb pattern is létezik a GoF-os DP-k 
mellett, bár tény, hogy a GoF könyv a legismertebb igehirdető- 
je a témának. Ha pontosak akarunk lenni, akkor a GoF által 
leírt minták OOP tervezési minták. De emellett még van na- 
gyon sokféle pattern, hisz a szoftvertervezés-írás nem csak 
OOP alapon történhet, valamint különböző szinteken is lehet 
megoldásokat keresni. 

A legnagyobb léptékű patterneket általában Architecture 
Patterneknek hívják. Ezek több alrendszerből álló nagy építő- 
kockákat mutatnak be. 

Közepes bonyolultságúak a jelen cikk és a GoF könyv fő téma- 
körét adó Design Patternek, amelyek egy-egy részfeladatra, 
rész-architektúrára adnak általános, nyelvfüggetlen megoldást, 
egymással kommunikáló komponensek képében. 

A legegyszerűbb minták az idiomok vagy más néven 
Programming Patternek. Ezek egy objektum belsejének részle- 
teivel vagy egy nyelv elemeinek használatával foglalkoznak. 
Például az egy C--4-os idiom, hogy a konstruktorban lefogla- 
lunk erőforrásokat, a metódusok használják őket, majd a 
destruktor felszabadítja őket. Vagy az is egy gyakori idiom, 
hogy egy metódus visszatérési értékét eltároljuk egy változóba, 
de rögtön össze is hasonlítjuk egy értékkel: 


if ((ido - GetTime()) s 60) ... 


Patterneket vethetünk be a tervezést megelőző fázisban, az 
analízisben is. Martin Fowler például írt egy könyvet Analysis 
Patterns címmel. Ebben egészségügyi és pénzügyi programok 
írásához kapunk 70 analízis- és tervezési mintát. Ez egy specia- 
lizált könyv, viszont pont emiatt az adott területekre (OOA) 
konkrétabb megoldásokkal tud szolgálni. 

Érdemes még tudni egy másik négyes által írt könyvcsaládról: 
ezek a Pattern-Oriented Software Architecture vagy POSA 
könyvek. A második rész címe: Patterns for Concurrent and 
Networked Objects. Ebben elosztott, hálózati alkalmazások 
fejlesztéséhez kapunk 17 DP-t. 

Azaz a GoF-ban leírtakon kívül létezik még jó pár specializált 
pattern leírás, amely egy-egy területre koncentrál. Amint a 
programozás egyre inkább átmegy művészetből tudományba, 
várhatóan egyre inkább nő a patternek jelentősége is. Jelen pil- 
lanatban ugyanis ez tűnik az egyik leghatékonyabb tudás-átvi- 
teli formának. 


Mi a DP-k lényege? 
A DP-k három alapvető technikát favorizálnak: 
HA Részesítsd előnyben a delegálást a leszármaztatással 
szemben; 
A Programozz interfészekkel szemben; 
AA Rejtsd el, ami változhat. 


Miért nem ajánlják a leszármaztatást? Amikor valaki elkezd 
OOP-t tanulni, általában nagyon megtetszik neki az, hogy 
egyik osztályból egy másikat leszármaztatva annak minden 
implementációja (kód és adattagok) rendelkezésre áll a leszár- 
mazott osztályokban is. 

Ez nagyon jó, azonban az öröklés statikus kapcsolat két osztály 
között, amely fordítási időben értékelődik ki. Ha egyszer a Ku- 
tya osztály az Állat osztályból származik, az összes viselkedé- 
se, tudása (metódusok) amit az állattól kap, fordításkor eldől, 
futásidőben már nem lehet rajta változtatni. 

Emellett a leszármaztatás merev is. Gondoljuk arra, hogy le- 
származtatok egy vezérlőt a TextBox osztályból. Ebben specia- 
lizálom a TextBoxot, hogy mondjuk csak telefonszámokat fo- 
gadjon el. 

Ezek után szükség van egy olyan TextBoxra, aminek a háttere 
piros. Leszármaztatom a TextBox osztályból, és mondjuk a 
konstruktorban pirosra állítom a háttérszínt. Ezek után szükség 
van egy piros hátterű, telefonszámokat elfogadó Textboxra. 
Még többszörös leszármaztatást támogató rendszerben sem tu- 
dom egyszerűen leszármaztatni a piros és a telefonszámos 
TextBoxból az új TexBoxot, hisz az így valójában kétféle 
TextBoxot is tartalmazna. Nincs mese, le kell származtatnom 
újra az alap TextBoxból, és újra kell implementálnom a két 
funkciót. Programozásban az egyik fő ellenségünk az ismétlő- 
dő kód. Itt triviálisan kopi-paszta öröklést használtunk (kódot, 
implementációt másoltunk). 

Mi az egész problémakör oka? Az, hogy az öröklés túl mere- 
ven bedrótozza a leszármazott osztály lehetőségeit. Nem tud- 
juk könnyedén kombinálni a szükséges szolgáltatásokat, így n 
féle lehetőség összes kombinációjának kihasználásához 2n 
féle osztályt kellene implementálni. Nem túl kecsegtető terv. 
Mit javasol erre a problémára a GoF könyv? Emlékezzünk csak 
az első alapelvre: 


HA részesítsd előnyben a delegálást a leszármaztatással 
szemben. 


Delegálás — ne az adott osztályban valósítsunk meg egy műkö- 
dést, hanem egy másik osztályban, és delegáljuk, dobjuk át a 
metódushívásokat. 

Keressünk egy olyan DP-t, ami passzol a problémánkra. Min- 
den DP-nek van egy Intent — Mire való? fejezete. Ebben a kö- 
vetkezőt találjuk a Decorator patternnél: 

Cél - , Dinamikusan (futásidőben) járulékos felelősségek hoz- 
záadása egy objektumhoz. A dekorátorok rugalmasabb funk- 
cióbővítési alternatívát biztosítanak a leszármaztatással szem- 
ben., 

Ez nagyon úgy néz ki, hogy passzol a problémánkra. A 
responsibility (felelősség) talán furcsa szó, de OOP terminoló- 
giában ez egy objektumtól elvárható szolgáltatásokra utal, 
azaz milyen működést, funkciókat várhatunk el tőle. 

A pattern struktúrája a következő: 
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És itt kerülünk bajba. A pattern használatához kellene egy alap- 
interfész (Component), amelyben minden egyes TextBox metó- 
dus össze van szedve. Ez nem feltétlenül egy interfész, hanem 
lehet absztrakt alaposztály is, vagy egy olyan konkrét osztály, 
amelyben minden metódus virtuális, azaz az összes metódusa 
polimorf módon újraimplementálható a leszármazott osztá- 
lyokban. Esetünkben azonban van egy konkrét TextBox osz- 
tály, amelynek van egy pár tucat metódusa. A pattern haszná- 
latához mindegyiket tovább kellene delegálni a Decorato- 
roknak, ami esetünkben nagyon nagy munka lenne, illetve a 
nem virtuális metódusok miatt egy részével nem tudnánk mit 
kezdeni. A pattern Inplementation fejezetében is írják, hogy a 
Component alaposztály legyen egyszerű, kevés metódust tar- 
talmazó. Esetünkben ez nem igaz. 

Így vérzett el a dekorátor pattern. A példa mutatja, hogy a 
patternek bevetésekor nagyon oda kell figyelni, mert egy, a 
problémára látszólag kiválóan alkalmazható pattern lehet, 
hogy valami apróság miatt mégsem használható. Szerencsére a 
Decorator pattern leírása során felhívják a figyelmünket arra, 
hogy abban az esetben, ha a Component alaposztály (TextBox) 
túl összetett és a Decorator osztályok túl bonyolultak lenné- 
nek, gondolkodjunk el a Strategy pattern használatán. 

A Strategy célja: 

,Definiálni egy algoritmuscsaládot, egységbezárva és cserélhe- 
tővé téve őket. A Stategy lehetővé teszi, hogy az algoritmus 
anélkül változzon, hogy az ügyfél (hívó) észrevenné ezt." 
Esetünkben két algoritmusról van szó. Az egyik megmondja, 
milyen színű legyen a háttérszín, a másik pedig leellenőrzi, 
hogy a begépelt karakterfüzér telefonszám-e? Azaz kétszer is 
be kell vetnünk a Strategy patternt. 





A pattern statikus UML osztálydiagramja a következő: 
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Esetünkben a Context, aki használja a Strategy interfészen de- 
finiált algoritmusokat a saját ,okos" TextBoxunk. Látható, hogy 
a Context aggregálja a Strategy interfészt, azaz a TextBoxunk- 
nak lesz egy-egy referenciája a háttérszínállító és a validáló 
stratégiára is. UML-ben így néz ki az osztálydiagramunk: 
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A megfelelő algoritmust tároló konkrét stratégiaimplementációt 
a MyTextBox konstruktorban adjuk át a textboxnak. Nézzük 
meg az UML diagramon látható osztályok konkrét implemen- 
tációját: 
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return Color.Red; 
3) 
Uj 
public interface IValidationStrategy ( 
bool IsValid(string text); 
string GetValidFormatt( ) ; 
, 


public class PhoneNumberValidationStrategy: 
IValidationStrategy ( 
public bool IsValid(string text) ( 
Regex re - new 
4 Regex(ea"Nd(2)-Md(2)-Nd(3)-Nd(4)"); 
return re.Match(ítext) . Success; 
y) 
public string GetValidFormat() ( 
return "dd-dd-ddd-dddd - Országhívó- 
b  Körzetszám-Teli1-Tel2"; 
bh 
ij 


Hogyan hozhatunk létre különböző típusú TextBoxokat? 


//egyelőre bedrótozott a statégiaobjektumok 
//létrehozása 

IBackColorStrategy bs - new 
RedBackColorStrategy( ) ; 

IValidationStrategy vs - new 
PhoneNumberValidationStrategy ( ) ; 


int i z -20; 

MyTextBox t - new MyTextBox(bs, vs); 

t.Location - new System.Drawing.Point(20, i4-40); 
t.Text - "Piros és validál"; 

Controls.Add(t) ; 


t z new MyTextBox(null, vs); 

t.Location - new System.Drawing.Point(20, i4-40); 
t.Text - "Csak validál"; 

Controls.Add(t); 


t z- new MyTextBox(bs, null); 

t.Location - new System.Drawing.Point(20, i4-40); 
t.Text - "Csak piros"; 

Controls.Add(t); 


Látható, hogy attól függően, hogy milyen stratégiaobjektumo- 
kat kap egy-egy MyTextBox példány, mindegyik másként visel- 
kedik 

Mi történik, ha kiderül, hogy kellene egy irányítószámokat is 
ellenőrző TextBox (ami persze lehet piros is)? Semmi gond, az 
előbbi ellenőrző stratégiánk telesen alkalmas erre a célra is, 
csak létre kell hozni egy új stratégiaosztályt, ami az IValida- 
tionStrategy-t implementálja: 


public class ZipValidationStrategy: 
IValidationStrategy 
( 
public bool IsValid(string text) 
6 
Regex re - new Regex(e"Yd(4)"); 
return re.Match(ítext) . Success; 
, 
public string GetValidFormat() 
( 
return "dddd - Az irányítószám négy 
$ számjegye"; 
3; 
J 


A megoldás (és általában a DP-k használatának) talán legszebb 
része, hogy az új funkcionalitás használatához semmit nem 
kell átírni, csak új kódot hozzáadni! Az új stratégiaosztály ké- 
szen van, már csak meg kell mondani egy új textboxunknak, 
hogy használja: 


IValidationStrategy zvs - new 
ZipValidationStrategy ( ) ; 

t - new MyTextBox(null, zvs); 

t.Location - new System.Drawing.Point(20, i4-40); 
t.Text - "Csak ZIP"; 


Ha megfigyeljük, a megoldás nagyon jól bővíthető, és magán 
viseli a DP-k mindhárom alapelvét: 

JA Részesítsd előnyben a delegálást a leszármaztatással 

szemben; 

HA Programozz interfészekkel szemben; 

A Rejtsd el, ami változhat. 
Mi változhat? A validálás vagy a háttérszín algoritmusa. Elrej- 
tettük őket a MyTextBox elől, így azokat legószerűen bármikor 
kicserélhetjük, anélkül, hogy erről bármi tudomása lenne a 
TextBoxkánknak. 


Összefoglalás 


A példa alapján sejthető, hogy DP-k ismeretében sokkal job- 
ban bővíthető és karbantartható kódokat írhatunk, mint tisztán 
saját kútfőből merítve. Akiket érdekelnek az objektumorientált 
analízis és tervezés részletei DP-k bevetésével, azoknak min- 
denképpen ajánljuk a 3 napos Design Patterns tanfolyamunkat, 
amelyben egy többnyelvű, többfelé adatbázison működő 
webalkalmazást építünk fel DP technikák felhasználásával, a 
cikkszerző vezetésével. 





A cikkben szereplő URL-ek: 
Letölthető példakód 
http://technet.netacademia.net/download/dp 


Soczó Zsolt MCSE, MCSD, MCDBA, MCAD, MCT 
Zsolt.Soczo€onetacademia.NET 


Kapcsolódó tanfolyamaink 


DP — Design Patterns 
http://www.netacademia.net/workshop/DP 
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Avagy ki látott már sikeres, határidőre 
befejezett, költségkereten belül 
maradó szoftverfejlesztési projectet? 


Ha egy fejlesztőcsapat fejébe veszi, hogy következő projektjét már nem bukja el, érdemes megismer- 
kednie az MSF keretrendszerrel. Ez ugyanis nem mást tartalmaz, mint a világ legnagyobb 
szoftvergyárában korábban előfordult bukásokból levont tanulságokat, és a ,kihívások" elkerülésének 


lehetőségeit. 


Az elmúlt évezred talán legnagyobb szoftverproject-bukása a 
Visual C-4-4- kifejlesztéséhez fűződik. A munka során ugyanis 
minden lehetséges és lehetetlen határon sikerült túlmennie a 
fejlesztőcsapatnak. Sem a határidők, sem a költségkeret nem 
állták ki a gyakorlat próbáját. A felelősök utólagos megkeresé- 
se és kijelölése" szintén kudarcot vallott. Vajon miért? 

Jim McCarthy, a fent nevezett Visual C--4 Business Unit ve- 
zetője a projekt után 23 ökölszabályban foglalta össze a sike- 
res fejlesztési projekt alapelveit ("23 rules of thumb for 
shipping great software on time"). Ebben rámutat, hogy 
annak ellenére az ügyfél és a managerek határozzák 
meg a projektek határidejét, hogy a fejlesztés pon- 
tos időigényéről a munka dandárját végző fej- 
lesztőknek sincs halvány elképzelésük sem! 

Nem meglepő módon az így kitalált határidők 
SOHASEM lesznek betartva. 

Az MSF-keretrendszerben éppen ezért java- 

soljuk a ,bottom up scheduling" eljárást, 
amikor a programozók (alsó szint!) becslik 

meg az egyes részfeladatok határidejét, amit 
azután a managerek csak összesítenek. Ez az 
eljárás azonban azt feltételezi, hogy a határidők 
felállítása előtt már tudjuk, hogy mit is akarunk csi- 
nálni. És ha ez sem teljesül...? 


Kézenfekvő megoldásnak tűnik: kérdezzük meg az ügyfelet, 
vajon mit akar? Sajnos azonban az ügyfelek döntő többsé- 
ge legfeljebb azt tudja, mi nem megy neki (sokszor még azt 
sem). Tehát adva van egy fejlesztési project, amiben nem is- 
mert célokat kell fix határidőre teljesíteni. Ha ehhez hozzá- 
vesszük, hogy az ügyfél minél több drága funkciót követel mi- 
nél kevesebb pénzért (és idő alatt) mi pedig minél több pénzt 
akarunk keresni, minél kevesebb munkával, látható, hogy a 
bukás garantált! 

Most nézzük meg, hogy egy ilyen, eleve bukásra ítélt fejleszté- 
si projekt során milyen további lehetőségek adódnak saját 
munkánk megnehezítésére! 


Kihívásokkal küszködik... 


Igen gyakori erőforráspazarlás, hogy a fejlesztők a szépség je- 
gyében módosítanak egy már letesztelt kódot (például bele- 


Az informatikai projektek 
sikeressége 

a Standish Group 
kutatásai alapján 


kezdenek egy jó nagy tárolt eljárás optimalizálásába), ami az 
ügyfélnek egyáltalán nem is fontos: maximum havonta egy- 
szer futtatja, és teljesen mindegy, hogy ilyenkor 2 perc vagy 
10 másodperc alatt fut le — igazából az sem zavarná, ha 1 órá- 
ba telne. 

Ez teljesen fölösleges munka, és elveszi az időt a fontos, na- 
ponta 1000-szer futtatott kódágak alapos elemzésétől, bugokat 
visz a már letesztelt kódba. 

Apropó bug: mi az a bug? Mit kell vele ten- 
ni? Gyakori, hogy a fejlesztők minden 
bugot ki akarnak javítani. Ezt tudo- 

mányosan issue (ügy) menedzs- 
mentnek hívjuk. Vegyünk egy 
konkrét példát: ha mondjuk 
egy HR szoftverben ellenőr- 
zés híján a munkatárs élet- 
kora 134 vagy 1 millió év is 
lehet, azt bugnak tekintjük- 
e? Az ügyfélszoftver haszná- 
latával a rendszer jól viselke- 
dik, de ha valami őrült közvet- 
lenül matat az adatbázisban, és 
hülyeséget ír be, akkor azt elfo- 
gadja, további számításokat végez 
vele (mikor megy nyugdíjba egy 
egymillió éves munkatárs?). Az 
ilyen bug kijavítását a project végé- 
re kell hagyni, mert nem fontos a 
javítása, a legtöbbször észre sem 
veszik. Kritikusabb a helyzet, ha el- 
fogadunk mondjuk 100 90-nál nagyobb kamatot, vagy éppen 
február 31-i teljesítést. De vajon TÉNYLEG ki kell ezeket javí- 
tani? Kockáztatni a build sikerességét és az átadást? Nem elég 
csak ledokumentálni (its a feature, not a bug), és majd a 
következő verzióban kijavítani? Hol a határ? 
Ebben a nehéz kérdésben segít az MSF bug/issue management 
része. 





a, kihívásokkal 
469 KITÍVÉGIK 





Hogyan kezeljem azt, ha az ügyfél mindent akar? 


A legjobb terv is arra való, hogy azután legyen mitől eltérni. 
Gyakran előfordul, hogy valami közbejön, és a csapat nem ké- 
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pes mindent határidőre , megkódolni". Az emberi hi- 
bákon túl (síbalesetet szenved az egyik főkóderünk) a 
környezetből (például lefagy a fejlesztői gépem két 
napra) és az ügyfél hozzáállásából fakadó hibák is 
közrejátszanak szép terveink rombadőlésében. Te- 
kintettel arra, hogy MINDEN szoftverprojekt alatt amúgy is in- 
goványos a talaj (lásd: az ügyfél nem is tudja, mit akar), érde- 
mes lehet a szerződésbe belevenni, hogy milyen irányelvek 
szerint térünk el, ha gáz van. GÁZ PEDIG VAN! 

Egy sikeres gáztervezési esetünkben az ügyfelünkkel sikerült 
előre megállapodni, hogy mely funkciók eshetnek áldozatul 
egy esetleges gáztámadásnak. Egyetértett, hogy a portálja fó- 
rum nélkül is elindulhat, és az adminisztrációban is találtunk 
tíz olyan kényelmi funkciót, ami nélkül tulajdonképpen simán 
el lehet kezelgetni az alkalmazást. 

Mit ad Isten, a cég PR-főnöke kitalálta, hogy egy héttel hama- 
rabb kell elindulni a tervezett időpontnál! A céltudatos terve- 
zés miatt ez esetben nem szenvedtünk gázmérgezést, mert a 
buildünk stabil volt minden nap, és ami utolsónak maradt (a 
fórum és a 10 kényelmi funkció) azt egyszerűen kidobtuk a 
projektből és nem is próbáltuk meg egy héttel kevesebb idő 
alatt befejezni, hisz jól tudtuk (szerencsére ez a szerződésben 
is benne volt!) hogy ez lehetetlen. A portál határidő előtt egy 
héttel elindult, és mindenki örült. (Persze még így is további 
egy hétig reszeltük az éles rendszert. Elképzelhető, mi lett vol- 
na, ha még a fórummal is megpróbálkozunk!) 

Sokan félnek az őszinteségtől, pedig a bizalom megszerzése a 
legfontosabb. Ha nem csalódnak bennünk, legközelebb is 
minket választanak. 

Az MSF trade-off matrix megtette a hatását. 


Titkolózás vs. őszinteség 


Az alábbi esettanulmány címe ez is lehetne: ki mit ért 60 kilo- 
bájtos képek kezelésén? Adva van egy project, melynek része- 
ként kisebb képfájlokat kell megjeleníteni a képernyőn. A meg- 
rendelő csak annyit mond a képekről: ne izguljunk, maximum 
60-70 kilobájtosak. 

Korábbi projektekben megedződött lelki szemeink előtt kicsi, 
színes igazolványképek lebegnek, és ennek megfelelően 
rittyentünk egy túlbiztosított, akár 100 k-s képek megjeleníté- 
sére is alkalmas ActiveX-vezérlőt. 

Minden rendben van, a build jó, stabil és gyors. Csakhogy a 
megrendelőnél a képkezelő ActiveX hatására az egész 
oprendszer simán, hibaüzenet nélkül újrabootolt! Mi az ördög? 
Reboot funkciót is belefejlesztettünk? 

1. Mi NT4-et használtunk 128 MB RAM-mal (jó régen 
volt) a külföldi ügyfelünk gépein viszont Win95 volt 32 
megával. 

2. Nem tudtuk, hogy ők a képkezelőt hatalmas, 5000 x 
3000 pixeles képekkel fogják túráztatni! A fájlméret 
stimmelt, 50-60k. Mivel csak ennyit tudtunk, azt hittük 
ezek maximum 800x600-as JPG-k. 24 bites színmély- 
séggel egy az egyben kirakattuk a Windows GDI-vel a 
képernyőre a megfelelő ablakba. 

A mi képeinkkel mindez 5-10 MB memóriát evett — hadd 
egyen! Csakhogy a 60k-s képek, amiket ők akartak kezelni, fe- 
kete-fehér 1 bites TIFF-ek (beszkennelt tervrajzok) voltak, és az 
24 bitben 120 MB RAM-ot kért. A Win95 ettől egyszerűen és 
csendesen lehasalt. Ki a hibás? Miért VB-ben írtuk meg ezt az 
egyszerű vezérlőt? Miért nem optimalizált C-t kódot raktunk 
alá? 

Azért mert nem tudtuk mi a cél, nem láttuk a kockázatokat, 
nem volt jó a management. 


Wir E.t W.§t A windows 


Ha MSF shared vision modell szerint dolgoztunk volna, min- 
denkiben tudatosult volna a cél: ,bazi nagy fekete-fehér képe- 
ket kell kezelni". Ennek tudatában biztosan nem VB-vel állunk 
neki a feladatnak, sőt, lehet, hogy nem is kliens-, hanem szer- 
veroldali képfeldolgozást javaslunk. 


Az MSF-keretrendszer 


Ennyi probléma után essék szó a megoldás lehetőségéről is. A 
Microsoft Solution Framework egy keretrendszer, amely szabá- 
lyozza az IT projektek folyamatait, ám mégis szabad utat enged 
a kreativitásnak, az újszerű megoldásoknak. Az MSF modellek 
gyűjteménye, melyeket mint szerszámokat bármikor előhúzha- 
tunk a szerszámosládából, ha a szükség úgy hozza. Ennek a 
megközelítésnek az a legfőbb előnye, hogy nem kényszerít ránk 
olyan modelleket vagy szabályokat, amelyek egy adott projekt 
lefolytatásához és sikerre viteléhez nem szükségesek. 

Az MSF alapjai a csapatmodell, a folyamatmodell, a proaktív 
támogatására bevezetett követhetőség, és egyéb hasznos ötle- 
tek. Ezen modellek alkalmazása több előnnyel is jár, ezek kö- 
zül a legfontosabb, hogy a csapat tagjai mindig tudják, mi tör- 
ténik, illetve mindig pontosan tisztába vannak azzal, hogy az 
adott részért ki a felelős. Így a csapat hatékonysága megnő, a 
határidő pontosan tarható, nincs költségtúllépés. 
Meggyőződésem, hogy a fenti mondatokat más szakértők 
anyagaiban is olvasták, és most az fordul meg a fejükben, hogy 
leírni könnyű, de teljesíteni valószínűleg lehetetlen. Az igazság 
viszont az, hogy noha ideális projekt nem is létezik, az MSF 
alapelveinek okos használatával több sikeres projektet végig- 
vittem, gyakran a megrendelő legnagyobb meglepetésére. Az 
MSF alkalmazása nem könnyű, sok gyakorlás kell hozzá. Meg 
kell küzdeni feletteseinkkel, ügyfeleinkkel, hogy rávegyük őket 
az alapelvek használatára. Az MSF tartogat néhány meglepe- 
tést, amiből párat alább felsorolok. 


Meglepetések 


Első meglepetés, hogy az MSF-csapatmodell elveti az egysze- 
mélyes projektfelelős koncepcióját, mert készítői azt vallják (és 
milyen igazuk van!), hogy egy átlagos IT projekt terheit nem 
képes egyetlen ember a vállán viselni, legyen bármilyen jó 
szakember. Ha mégis kiváló vezető, akkor is nehézségbe ütkö- 
zik, hiszen ellentmondásos érdekeket kell magában egyeztet- 
nie. Az MSF-csapat ezzel szemben hat egyenlő szerepkörre 
épül, ahol mindenkinek megvan a maga felelősségi területe. A 
szerepkörök feladatai sokszor ellentmondanak egymásnak. A 
csapat akkor működik jól, ha a hat szerep képviselői konszen- 
Zzusra jutnak, amire az MSF konkrét utakat, módszereket jelöl 
ki. A szerepek kisebb projekteknél összevonhatók, így a legki- 
sebb MSF-csapat háromtagú lehet. 

A csapatmodell hat szerepköre és felelősségi területei a 
következők: a Product Manager felelős az ügyfél elégedettsé- 
géért, a Program Manager felelős a fejlesztés gördülékeny ha- 
ladásáért, a Development felelős azért, hogy a rendszer a spe- 
cifikációnak megfelelően, határidőre készüljön el, a Test fe- 
lelős a termék minőségéért, a User Experience felelős a végfel- 
használók igényeinek figyelembevételéért és oktatásáért, és vé- 
gül, de semmiképpen sem utolsó sorban a Release Manager fe- 
lelős a rendszer üzembehelyezéséért. Jól látszik, hogy a 
Product Manager és a User Experience között konfliktushelyzet 
alakulhat ki, hiszen a termékfelelőst az alacsony ár érdekli, míg 
a felhasználók felelősét a minél gazdagabb felhasználói él- 
mény, ami pedig költséges. Ezt egy csapat sokkal hatékonyab- 
ban tudja feloldani, mint egyetlen felelős. 
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Az MSF folyamatmodellje egy módosított spirálmodellre épül, 
amely ötvözi a vízesésmodell és a spirálmodell előnyeit. Az 
MSF legújabb, harmadik változatában egy projekt öt részből 
áll. Az első az Envisioning, melynek során megszületik a pro- 
jekt víziója, és eldöntetik, hogy annak mely részei fogják a pro- 
jekt kereteit képezni. A következő fázis a Planning, melynek 
során a vízió megvalósításra kiválasztott részeit részletesen 
megtervezik és elkészül a projektterv. A harmadik a Develop- 
ment, ennek a végén már kész termék jelenik meg, ami már 
csak stabilizálásra szorul. A Stabilizing fázis végén tehát a ter- 
mék elnyeri végső, telepítésre alkalmas alakját, és ezzel belé- 
pünk az ötödik, Deployment fázisba. Fontos, hogy a hat szerep 
minden negyedben egyformán aktív. A Test szerep például már 
a víziót vagy a terveket is ellenőrzi, teszteli, állandóan hibákat 
keres. A Release Manager szintén már a legelején aktív, min- 
den felmerülő ötletet elemez az üzemeltetés szempontjából, 
így nem a végén derül ki, hogy egy nagyszerű funkció esetleg 
nem képes működni a rendszer valós környezetében. 

A kockázatkezelés a projekt teljes időtartama alatt működik, ez 
miden csapattag felelőssége. A kockázati tényezőket doku- 
mentáljuk, rangsoroljuk, majd felelősöket rendelünk hozzájuk. 
Így ha a kockázat problémává válik, azaz bekövetkezik egy 
nem várt esemény, az valójában várt esemény lesz, és doku- 
mentálva lesznek a tennivalók. Ennek a főnökség és a megren- 
delő egyformán örül, de csak akkor működik, ha őszinték va- 
gyunk egymáshoz, és elsősorban magunkhoz. 

Az utolsó három fázis alatt működik a hibakövetés, feladata a 
szoftverben keletkező hibák felderítése, illetve feldolgozása. Fő 
felelőse a Test szerep, illetve a Development csapat. 


Az MSF ereje 


Az MSF ereje abban rejlik, hogy a megrendelőt is a fejlesztői 
csapat részeként kezeli, nem zárja ki a tervezésből, a 
tesztelésből és a kockázatok kezeléséből. Ha van olyan érv, ami 
igazán az MSF alkalmazása mellet szól, akkor ez az. Ilyen kér- 
dés a határidők megszabása, amely hagyományosan már akkor 
lezajlik, amikor még azt sem tudjuk pontosan, mi a feladat. 

Az MSF a határidőket úgy tartja be, hogy pontos modellt ad a 
határidők, a rendelkezésre álló emberi és anyagi erőforrások és 
az elvégzendő feladatok közötti egyensúly meghatározására. 
Ez párosul azzal az alapelvvel, hogy a határidőket azok becs- 
lik meg az egyes feladatokra, akik a feladatot végzik. Így a pro- 
jektmenedzsment nem kerül abba a helyzetbe, hogy irreális 
határidőket szabjon meg a programozóknak. 


MSF a Microsoftnál — a Daily Build 


Végül megemlítek egy kevéssé ismert fejlesztőcéget, 
akik sikeresen használják az MSF-keretrendszert: ez 
a Microsoft maga. A teljes rendszerből az úgyneve- 
zett napi buildet vegyük górcső alá. 

A Microsoft saját magán szerzett keserű tapasztalataiból szár- 
mazik a mindennapra egy build technika. A build nem más, 
mint az összes forráskód összefordítása egy (féllkésztermékké. 
A napi build arra jó, hogy azonnal kiderülhessen, vajon egyál- 
talán összefordítható-e még a sok fejlesztő által elszigetelten 
készített forráskód, vagy szétszaladtak a lovak. 

Emellett — ha minden jól megy — minden nap, minden este ké- 
szül egy stabil rendszer, amit ha kell, akár holnap szállíthatunk! 
A napi build abban is segít, hogy minden főnök láthassa, a 
szoftver ,hogy is áll" egy adott pillanatban. Ha a daily build 
nem készül el napok óta, az jelzés, hogy valami nincs rendben. 
A daily build úgy készül, hogy minden fejlesztő minden reggel 
leszedi a többi fejlesztő előző stabil kódját, és annak birtoká- 
ban fejleszti tovább a maga részét. Így elkerülhető, hogy ősi 
verziókkal feleslegesen küzdjön. Ha valamit befejezett, azt a 
saját gépén ,buildeli" és teszteli is egyben. (Nem vár a tesz- 
telőkre! Ő maga is tesztel!) 

Ha ez a lépés sikeres, beküldi a kódot a buildelőknek. A napi 
build sok-sok programozó összes beküldött kódjából áll össze 
— ha összeáll. Ha nem sikerül a build, azt a kódot, ami miatt 
nem áll össze, visszadobják a bűnösnek, tegnapi kódja kerül a 
buildbe, és másnap már az új buildhez kell hozzáigazítania a 
kódját. Fordítás és linkelés után az új build lesz az aktuális, ezt 
lehet hagyományos módszerekkel tesztelni. A Microsoftnál 
minden éjszaka tesztelnek, aminek eredménye, hogy a másnap 
reggel 9-kor tartott meetingen már hibalisták (bugreport) állnak 
rendelkezésre! Fontos megjegyezni, hogy a bűnös programo- 
zó, aki miatt a build nem állt össze nem büntetést, hanem se- 
gítséget kap. Meglepő, ugye? 

Az MSF működik. Eddigi legnagyobb projektem, amit az MSF 
segítségével határidőre végeztünk el, 1 millió euró költségve- 
tésű volt. 


— 


Bíró Tamás (MCSD) 
btGsensenet.hu 
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) III. rész -— the X files 


Sorozatunk" első két részében sokat emlegettük a különféle x-szel kezdődő fájlokat, elsősorban az 
XML-t és az XSLT-t. Arról azonban kevés szó esett, hogy pontosan milyen szerepet is kapnak az X-fáj- 
lok egy portál életében, illetve hogyan kell őket alkalmazni egy többrétegű korszerű portálmegoldás 


fejlesztése közben. Az igazság ezúttal ideát van. 


Az XML és XSLT transzformációt a legtöbb portálmegoldásban 
az XML-fájlok HTML-re konvertálására használják, azaz az 
XML a kapcsolat az üzleti logika és a prezentáció között, és az 
XSLT maga a prezentációs réteg. Az XML azonban ennél töb- 
bet tud. 

Az XML-technológia helyes alkalmazásával valóban könnyen 
fejleszthetők igazi többrétegű, komponensalapú alkalmazá- 
sok. Amennyiben a részegységek XML-fájlokon (streameken, 
adatfolyamokon) keresztül kommunikálnak egymással, ame- 
lyek előre definiált szerkezettel (sémával) rendelkeznek, és 
pengeélesen elhatárolódnak egymástól, lehetővé válik, hogy 
egymástól függetlenül fejlesszük, vagy akár kicseréljük őket. A 
régi, nem XML-alapú komponensek egy kommunikációs réteg 
megírásával könnyen illeszthetők XML-hez. A már eleve xml- 
t küldő és fogadó alkalmazásokat pedig egyszerűen lehet il- 
leszteni: vagy módosítani kell a kommunikációs rétegen, vagy 
XSLT transzformációt kell alkalmazni. 

Az XML technológia tehát nemcsak a prezentációban kap sze- 
repet. Bárhol használhatjuk, ahol komponensek kapcsolód- 
nak, azzal a különbséggel, hogy a prezentáció mindenképpen 
megkívánja az XML transzformálását valamilyen más fo- 
gyasztható formátumra, míg az egyéb komponensek közötti 
kommunikációhoz nem feltétlenül kell átalakítást végezni. A 
dolog igazi szépsége a szerepek megmaradása. Az adatforrás 
előállít, a megjelenítő megjelenít. Például egy ügyféllistát 
előállító komponensnek nem kell foglalkoznia azzal, hogy a 
kimenete hova kerül, hiszen az általa szolgáltatott XML 
transzformálható HTML-lé, vagy — további feldolgozás céljá- 
ból — illeszthető egy másik komponens bemenetére is. Ezáltal 
érvényesül az xml egyik legfontosabb elve, miszerint az adat 
elválik a megjelenéstől, csak a tartalomról hordoz metainfor- 
mációt, annak feldolgozásáról nem. 

Az xml technológia a strukturáltságot és az uniformizmust 
hozza be a komponensek közötti kommunikációba. A modern 
portálmotoroknál ez a tény fokozottan előtérbe kerül, mivel 
nemcsak az egyes belső komponensekkel kell sakkozni, ha- 
nem a portált a környezetbe is be kell illeszteni, már meglévő 
komponenseket és külső alkalmazásokat is integrálni kell. Ek- 
kor realizálódik az az előny, hogy a komponensek azonos 
nyelven beszélnek. 


Az X-fájlok 

A technológia mindhárom főszereplője W3C szabvány. Azo- 
nos nyelvtant használnak, hiszen az xslt és az xsd is xml fáj- 
lok. Így ha valaki (vagy valami) tud xml-t olvasni, akkor sé- 
mát és transformert is képes. 

Az XML az eXtensible Markup Language, az XSLT az eXten- 
sible Stylesheet Language for Transformations, az XSD pedig 
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az XML Schema Definition szavakat takarja. Félreértésre ad- 
hat okot az XML értelmezésben a language, és az XSLT-ben a 
stylesheet szó. Helyesebb értelmezés szerint az XML nem 
nyelv, csak szintaxis, nyelvvé akkor válik, amikor egy sémá- 
val (XSD) előírjuk a szerkezeti és tartalmi elemeit. Tehát itt a 
kulcsszó az extensible. Valamint az 
XSLT nem stylesheet, hanem teljes 
értékű programnyelv, amit XML for- 


Az AIMIL-technológia — rás átalakítására találtak ki, itt a 
kulcsszó inkább a language és a 
helyes alkalma: transformation. 
zásával valóban Az XML. és az XSD 
Abból, hogy a komponensek közötti 
könnyen fejleszthe- kommunikáció nyelve xml, két fon- 
tos előnyünk származik. Tudjuk, 
tők igazi többrétegű, hogy egy üzleti szoftver fejlesztése 
ma már nem képzelhető el mások ál- 
komponensalapú tal megírt komponensek felhasználá- 
sa nélkül. Mivel a komponensek a 
alkalmazások. legkülönfélébb adatokat illetve ob- 


jektumokat kérnek és szolgáltatnak, a 

fejlesztés idejének nem elhanyagol- 
ható része a komponensek közötti adatcsere összehangolása. 
Az egyik előny ennek az időnek a jelentős csökkenése, hi- 
másik, hogy így az alkalmazások akár a weben is kommuni- 
kálhatnak egymással (pl: webservice, SOAP), hiszen az XML 
karakteres adatfolyam, így átvitele semmilyen problémába 
nem ütközik. 
Az XML tehát adathordozó. Mivel bonyolult struktúrák is 
leírhatók vele, helyes alkalmazásával nemcsak egyes adatok, 
tömbök, hanem teljes objektumok is átvihetők, szerializálha- 
tók vele (természetesen a metódusok nem). A .NET frame- 
work meg is valósít egy olyan névteret, amelyben XML-sze- 
rializációt segítő osztályok vannak. Valójában a webszolgál- 
tatások által használt SOAP-protokoll is így visz át objektu- 
mokat. 
Ha szoftverkomponenst készítünk, annak be- és kimeneti 
adatstruktúráit alaposan dokumentálnunk, valamint a beme- 
neti adatokat ellenőriznünk kell. Ha komponensünk XML be- 
meneteket vár és XML kimeneteket produkál, ismét előnyben 
vagyunk. Az XML formátumát sémával (XSD) írjuk le. Már az 
is előny, hogy ha példa XML-eket mellékelünk a be- és kime- 
netekre, azokat egy gyakorlott szem általában azonnal átlát- 
ja, ám a séma használatával teljes értékű és szabványos nyel- 
vű dokumentációt, valamint validációs eszközt nyújtunk. 
Az XSD-vel (lásd a szabványt a [Ischemal] címen), szinte min- 
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dent előírhatunk a várt formátummal kapcsolatban. Szabá- 
lyozhatjuk az elemek sorrendjét, mennyiségét és adattípusát 
is. Az XML érvényesítése sem probléma, hiszen ez teljes egé- 
szében a technológia sajátja. Egy XML támogatást nyújtó kör- 
nyezetnek tudnia kell validációt végezni akár úgy is, hogy a 
séma nincs is a lokális gépen, csak az Interneten át érhető el. 


Az XSLT 


Az X-fájlok közül az XSLT megértése szokta a legtöbb problé- 
mát okozni, mivel elsőre nem igazán érthető, hogyan műkö- 
dik. A most következő fejezetek nem kívánják az XSLT nyelv 
részletes bemutatását, azt megtették mások, csupán gondolat- 
ébresztőnek szánom őket, valamint egy-két érdekes probléma 
megoldását szeretném megosztani a kedves Olvasóval. 

Az XSLT feladata a transzformálás. A bemenete mindig XML, 
a kimenete pedig háromféle lehet. Ha a feladat csatolás egy 
másik komponenshez, a kimenet pedig XML, ekkor transzfor- 
mernek szoktuk hívni. Ha a feladat prezentáció, lehet text (pl. 
email body), vagy HTML, ekkor megjelenítőnek, renderernek 
is szoktuk nevezni. A felosztás nem teljesen egzakt, mivel pél- 
dául WML prezentáció is generálható, ami szintén XML szin- 
taxisú. Az XSLT működése ugyanaz akármilyen kimenete is le- 
gyen. Az XSLT jól megfér a megszokott CSS-sel is, mivel más 
a feladatuk. A stíluslap ugyanúgy használható külső fájlként, 
vagy inline scriptként, mint eddig. A prezentáció teljesen 
transzparens, hiszen szerveroldalon generált HTML is csak 
HTML, a lényeg a bemeneten van. Ha a bemenet XML, azt a 
leghatékonyabban XSLT-vel tudjuk transzformálni, megjelení- 
teni, akár spártai egyszerűségű, akár csilli-villi zizgő-mozgó 
oldalakról van szó. 

Fontos előny a szerveroldali scriptekkel szemben, hogy míg 
azok csak a webszerveren futnak, addig az XSLT kliensoldalon 
is futtatható. Ez esetben a szervernek csak a nyers adatokat 
kell szolgáltatnia, a prezentációt és a felhasználói inputok el- 
lenőrzésének egy részét kliensoldalon is el lehet végezni. Eh- 
hez a meglévő adatokon, és az üzleti logikán semmit, vagy 
csak alig kell módosítanunk. Az is nagy erőssége az XSLT-nek, 
hogy nem értelmezett, hanem lefordított kódként fut. Ha a fut- 
tatóobjektumot létrehoztuk, és feltöltöttük a forráskóddal, 
az lefordul, és ezt a csőre töltött objektumot akár cache-elhet- 
jük is. A transzformálás így annyira gyors lehet, hogy még egy 
nagyon nagy portál HTML fájljait sem kell statikusan legene- 
rálni. 

Most pedig lássuk az XSLT működését közelebbről! 


XSLT at work 


Minden kódvégrehajtó egység rendelkezik bizonyos láthatat- 
lan alapfunkciókkal, amelyek mindig végrehajtódnak. A szek- 
venciális végrehajtók (mikroproci, értelmezőprogram) például 
az utasítás beolvasása után a következő utasításra állnak, vagy 
függvényhíváskor veremben tárolják a visszatérés helyét. Az 
XSLT nem így működik, hanem context-nodeokat jelöl meg a 
forrás XML-ben, node listákba válogatja az elemeket, és sab- 
lonokat párosít, beépített algoritmust nyújt a rekurzív fabejá- 
rásra is. A dolog egyáltalán nem öncélú. A rekurzív fabejárást 
a szokásos iteratív nyelveken sem nehéz megvalósítani, de ezt 
teljesen felesleges minden alkalmazásban megírni, mivel a 
feldolgozandó adatstruktúra mindig egy fa, és mivel minden 
fabejáró ugyanazt a logikát követi. Gyakorlatilag az XSLT en- 
nek minden gondját-baját leveszi a vállunkról, és elrejti. 

Az XSLT rekurzív nyelv. Nincs FOR... NEXT, DO... LOOP, 
nincs tömb, sőt még a változók is más értelmet nyernek. Sok 
minden másképp működik, mint a megszokott programnyel- 


vekben, de ez egyáltalán nem idegen az emberi 
gondolkodásmódtól, főleg a programozókétól. A 
programozók már a kezdeti időktől fogva makrókat, 
blokkokat, függvényeket írnak, és később a híváskor 
egyetlen utasításban hivatkoznak rá. Ezekben a na- 
gyobb egységekben természetesen további hivatkozások le- 
hetnek — elvben akármilyen mélységig. Az így kapott algorit- 
musok szorosan összefüggenek a feldolgozandó adathalmaz 
struktúrájával. 
Az XSLT filozófiája hasonló, csak nem a szekvencia, hanem a 
blokk kerül előtérbe, kiegészülve a szelekcióval, valamint az- 
zal, hogy mindig van (legalább egy) meghatározott bemeneti 
fastruktúrájú adathalmaz. A szelektálás XPath nyelvű, amely 
egyszerűsége mellett, igen bonyolult lekérdezéseket tesz le- 
hetővé a bemeneti XML-ből. 
A szelektálás miatt az XSLT-vel való munka inkább az SOL-re 
hasonlít, mint a szekvenciális programvégrehajtásra: egy lé- 
pést egy szelektált halmazon kell értelmezni. A szelektált hal- 
maz egyes elemein az XSLT végrehajtó végiglépked (mintha 
egy forward-only kurzor lenne), egy illeszkedő sablont keres, 
és ha talál, azonnal elkezdi annak 
végrehajtását. A halmaz éppen aktuá- 
lis elemét hívjuk context-node-nak 


A szelektálás miatt (az adott sablonban a context-node 
ki XPath reprezentációja mindig egy 
az KSLT-vel való pont. A megkezdett új sablon új le- 


kérdezéseket tartalmazhat, ami egy új 
munka inkább az SOL- halmazt hoz létre, és annak elemeire 
szintén sablonokat keres a végrehaj- 
tó. A halmaz következő elemére csak 
akkor lép, ha egy sablonban nincs 
a szekvenciális Drog" . szelekció, vagy az adott elemre nincs 
találat. A halmazok előállítása, az 
azon való lépegetés, és a sablonok 
keresése automatikus, nekünk nincs 
más dolgunk, mint előírni a sablono- 
kat, a lekérdezéseket, és természetesen azokat a statikus ele- 
meket, amelyek változtatás nélkül kerülnek a kimenetre. 
Tulajdonképpen az XSLT-kód néhány definíció-, és feldolgo- 
zási utasítást leszámítva nem is áll másból csak sablonokból, 
azokon belül pedig statikus outputból, és szelekciókból. 
Az alábbiakban nézzünk meg egy-két gyakorlati példát, mi- 
közben nagy lépésekben átvesszük az XSLT alapjait is! 


re hasonlít, mint 


ramvégrehajtásra. 


Egy példa: adatáramlás a legalsó szintről a legfölsőre 


Legyen a feladat egy (nem létező) ügyféllista megjelenítése. Eh- 
hez adott egy SOL adatbázistábla (tbICompanies) az alábbi 
mezőkkel: CompanyID, Name, Address, Email. Az adatkezelő 
réteg egyik metódusa, mondjuk a GetCompanyList(), lekérdezi 
a táblát az SOL Server XML-támogatását segítségül hívva 
(SELECT " FROM tblCompanies FOR XML AUTO, ELEMENTS), 
ami a következő adatfolyamot produkálja: 


ctblcompaniesz 
CompanyID51c/CompanyID5 
cNamesTargonca Kft.c/Names 
-AddresssBp. 1921.c/Addressz 
cEmailsinfogtargonca.huc/Emails 
c/tblcompaniesz 


ctblCcompaniesz sé 
cCompanyID:2c/CompanyID2 
cNamesDuna Bt.c/Namez — 
cAddresso:Bp. XXXI. Ezer tér 1.c/Addressz 
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Ez egy XML fragment, ami önmagában nem érvényes XML, mi- 
vel nincs sem XML deklarációja, sem gyökéreleme. Ez a fajta 
lekérdezés így működik és kész. Ezzel az adatfolyammal több- 
féle dolgot tehetünk. Betölthetjük egy már létező DOM docu- 
ment valamelyik element-jébe mint inner-xml. Vagy ami szá- 
munkra most fontosabb: átalakíthatjuk egy másfajta XML-lé. 
Szerencsére az XSLT transformert nem zavarja, hogy csak XML 
fragmentet kell feldolgoznia. Tehát a kapott adatfolyamot a kö- 
vetkező XSLT transzformerrel illesztjük az üzleti logika beme- 
netére, amely XML-XML transzformációt végez (a leírására 
még visszatérek): 


A transzformer kimenete lesz az üzleti logika bemenete, ami 
egy szerializált objektumkollekció. Ez az első kapcsolódási 
pont az alkalmazásunk komponensei között. Mivel a jelenlegi 
példánkban az üzleti logika nem nyúl a listához, csak például 
ellenőrzi a jogosultságot, és bejegyzi a lekérdezés tényét a log- 
fájlba, ez lesz a kimenet is a második kapcsolódási pont, a pre- 
zentációs réteg felé: 


A prezentációs rétegnek, jelen esetben egy böngészőnek az 
alábbi scriptet szánjuk: 


Ezt megkaphatjuk például a következő egyszerű, de teljes érté- 
kű megjelenítőtől: 


ZÁ clients - Microsoft Internet Explorer 


Bp. 1921. [info (Otargonca.hu 
B: XXXI. Ezertér 1. — finfo(dduna.hu 


E Ezt a megjelenést várjuk el 


A fent leírt folyamat teljesen tipikus. Jól látható az alkalmazás 
több rétege és az azok közötti illesztés. Ha a fenti alkalmazás- 
ban például az adatkezelő réteget le kell cserélni (mert például 
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más a platform és nem áll rendelkezésre SOL Server vagy más 
alkalmazásból jön az adat), csak az adatkezelő- és az üzleti lo- 
gikai rétegek közötti illesztést kell átalakítani. Az, hogy a 
transzformálást melyik réteg végzi, az eredmény szempontjá- 
ból lényegtelen. A példában a prezentációs réteg tulajdonkép- 
pen az XSLT, valamint az a logika, amelyik meghatározza, 
hogy melyik megjelenítőt kell használni, és az a kód, amelyik 
fizikailag meghívja a transzformáló metódust. 

És most nézzük meg részletesen a legutóbb leírt megjelenítőt! 
Az első sorból megtudjuk, hogy XML szintaxisú fájlt olvasunk, 
a 2.-ból, hogy a tartalma egy XSLT, és a 3.-ból, hogy hatására 
HTML output keletkezik. Az 1-2. és 29. sorok szükségesek mi- 
nimálisan egy helyes transformerhez. Az "xsl:template" elemek 
(4-13, 14-18, 19-23, 24-28. sorok) az igazi műveletvégzők, 
ezek alakítják a kérdéses XML elemet a megfelelő kimeneti 
részfává. Az "xsl:apply-templates" elemek (10, 16, 21. sorok) 
végzik a rekurziót az adott elemen belül, ezek állítják elő azt a 
halmazt, amely elemeire template-t kell keresni. Végül a 26. 
sorban lévő "xsl:value-of" elem az, amelyik a forrás XML-ből 
adatot emel át a kimenetre. A többi sor statikus tartalom, amely 
változatlanul kerül a kimenetre. 

A fent leírt megjelenítő azért lehet ennyire egyszerű, mert a be- 
meneti és a kimeneti fa nagyon hasonló, nem ugyanaz, de 
"ugyanarra megy": ahol a forrásfa bejárásakor lefelé lépünk, ott 
a kimeneti fa generálásakor is al-elemet hozunk létre. A másik 
egyszerűsítés, hogy minden információhordozó elemet azonos 
módon jelenítettünk meg, sőt azok logikailag is egyenértékűek. 
Ez a való világban természetesen sohasem fordul elő, de arra 
jó, hogy áttekintsük a transformer működését. 

Ami nem egészen nyilvánvaló: az XSLT rendelkezik egy beépí- 
tett sablonnal, amely alapállapotban a gyökérelem text() node- 
jait jeleníti meg (vagyis összefüggő szövegfolyamként, szókö- 
zök, tabok és enterek nélkül megkapjuk az XML-ben lévő 
összes olyan szöveget, amelyek nincsenek a "c" és a "5" közé 
Zárva). A részletek a [built-in-rule] címen olvashatók. A lényeg, 
hogy ezt felül kell definiálnunk, azaz meg kell adnunk egy 
alapszabályt, amely akkor lép érvénybe, amikor elkezdődik a 
transzformálás, ha magyarul mondanám: a context-node az 
XML Document. Az alapszabály leggyakrabban így kezdődik: 


cxs1l:tempi; 





Fontos tudni, hogy ebben a sablonban nincs context-node 
(más felfogás szerint a context-node a teljes dokumentum), te- 
hát ebbe a sablonba azok a dolgok kerülhetnek, amelyeknek 
az adattól függetlenül meg kell jelenniük a kimeneten. Az alap- 
szabályban leírt "apply-templates" utasítás (710. sor) az, amely 
használható context-node-ot választ ki a forrás XML-ből. Pél- 
dánkban ez a cCCompaniesz elem. Erre az elemre a 14. sorban 
kezdődő sablon illeszkedik, tehát annak végrehajtása követke- 
zik teljes rekurzióval. Majd ha az teljes egészében befe- 
jeződött, folytatódik a 11. sorban ennek a sablonnak a végre- 
hajtása. 


Az "apply-templates" alakjai 

Ez az XSLT nyelv egyik legfontosabb utasítása, amely több 
alakban létezik. Az egyik, a "select attributummal ellátott ver- 
zió hatására összeáll egy halmaz (node-list), amely a context- 
node-hoz képest relatív XPath-nak megfelelő elemekből fog 
állni, majd ezekre egyenként sablonokat keres a végrehajtó. A 
másik alak a "select" nélküli verzió, ez arra utasítja a végrehaj- 
tót, hogy a context-node részfáját teljes egészében járja be, és 
úgy alkalmazza a sablonokat. Ezzel a "mindent egyberv szelek- 
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cióval vigyázni kell, mert amennyiben a találati no- 
de-list valamelyikére nem lehet sablont illeszteni, az 
a beépített sablonnal megy ki, vagyis a text() node-jai 
lesznek az outputra másolva. Ilyen esetben célszerű 
egy olyan sablont alkalmazni, amelyik lenyeli a sab- 


lon nélküli node-okat. Alább egy ilyen sablon látható, ez ki is 
írja a kérdéses elem nevét három csillaggal megjelölve, ami 
komolyabb XSLT építése közben hasznos lehet: 





Ez a megoldás az XSLT-sablon beépített prioritásai miatt mű- 
ködhet, amely szerint a nevesített sablonok (amelyek "match" 
attributumában egzakt név van) nagyobb prioritást élveznek a 
wildcarddal szemben. A prioritásokról érdemes megnézni a 
szabványt a [conflict] címen. 

Ha több azonos nevű elem van az xml-ben, de másképp kell 
őket megjeleníteni, nem a prioritást kell változtatni, hanem a 
sablon "match" attributumában az elem nevén kívül például 
szerepeltessünk annyi parentet, amennyi elég a megkülönböz- 
tetéshez, pl: Name helyett Company/Name. 


Melyik legyen: apply-templates vagy for-each? 

Feljebb láttuk, hogy az XSLT alapműködése a szelekcióra al- 
kalmazott automatikus sablonkeresés és végrehajtás. Azonban 
nemcsak az "apply-templates" utasítást használhatjuk szelektá- 
lásra, hanem a "for-each" utasítást is. Ebben az esetben ele- 
gendő egyetlen sablon is. Felfedezhető a hasonlóság az ASP- 
vel, miszerint adott a HTML váz, amelybe a megfelelő helyre 
beiktatjuk a dinamikus elemeket. Ez az egyszerűsége és átte- 
kinthetősége miatt csábító lehet. Viszont csak abban az eset- 
ben ésszerű a használata, ha egy XML elemet csak egy helyen 
kell megjeleníteni. Az első példa 4-28. sorait cseréljük le az 
alábbiakra: 





Ezen kívül látható, hogy az egyes sorok context-node-jai (a 
cCompany5 elemek) abszolút eléréssel vannak szelektálva, 
ami rugalmatlan, mivel ha megváltozik az XML-ben a cCom- 
paniesz helye, át kell írni a transformer minden abszolút 
XPath-át, míg az eredeti példában csak a cCCompaniesz elemét 
érintené a változás. 


Ha az eredeti példa sablonjait összehasonlítjuk a bemeneti 
XML-lel, nem nehéz észrevenni az objektumorientált gondol- 
kodást sem. Mivel a bemenet egy objektum-kollekció, van 
benne egy sablon, amelyik az egész kollekcióra vonatkozik: 
8 43. ú § 
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Portál Paraldigmal 


Ez a felfogás egyrészt átláthatóbbá teszi az egész alkalmazást, 
mivel az egyes objektumok belső reprezentációja megegyez- 
het. Ugyanilyen property-kkel rendelkezhetnek, tehát csak egy 
modelre van szükség. Másrészt bonyolult megjelenítés esetén 
maga az XSLT is könnyebben fejleszthető. 


Váltózók és paraméterek 


Az XSLT-ben használhatunk a teljes transformerre nézve globá- 
lis, és az egyes sablonokban érvényes lokális változókat is. 
Ezen kívül a sablonokat paraméterekkel is elláthatjuk, sőt glo- 
bális paramétereket adhatunk át a transzformert létrehozó ob- 
jektumból. Ilyen paraméter lehet például színkód, CSS fájlnév, 
vagy bármilyen adat, amely a megjelenítést vezérelheti. A pa- 
raméterátadás jól látható az alábbi Ctt függvényben: 





Ez a függvény egy stringben kapott XML-t transzformál úgy, 
hogy az XSLT-forrást a fájlrendszerből veszi, valamint az éppen 
aktuális időt átadja a transzformer objektumnak. Az XSLT-t ter- 
mészetesen fel kell készíteni a paraméter fogadására. Az áta- 
dott paramétereket egyedi névvel kell ellátni, mindegyiknek lé- 
teznie kell, és az XSLT-beli deklarációt csak a "transform" elem 
közvetlen gyermekeként lehet szerepeltetni. 

A paraméter deklarációja: 


ELOLVASTAM ENNEK A 
PORTÁLPROGRAMNAK A 
TERVDOKUMENTÁCIÓJÁT. 


TERMÉSZETESEN 
MINDEN VILÁGOS, 
DE AZÉRT... 





És felhasználása: 





Végül álljon itt egy érdekes effektus. Ha az első példakód 19- 
23. sorait az alábbira cseréljük, a táblázatunk sorai váltakozó 
színnel jelennek meg, és a kurzor alatti sor is meg van jelölve 
(highligh1). 





Az effektus egy egyszerű HTML trükk. A hatást a TR-elemek 
háttérszínének váltogatásával érjük el. A háttérszínt egy előre 
beállított változó (color) segítségével írjuk be a megfelelő he- 
lyekre (14. és 18. sor). A változó deklarálása és értékadása a 2- 
8. sorokban történik. 

Ennek a példának, és még sok más (ennél jóval összetettebb) 
megoldásnak az ismertetését a következő cikkünkben foly- 
tatjuk. 


Gyebrovszki Zoltán 
gzOsensenet.hu 


http://vilagokorseg.hu 
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Petri -hálók modellezése És 


analízise 
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A korábbiakban bemutattam a Petri-hálók működését. Most egy kicsit gyakorlatiasabb oldaláról igyek- 
szem megközelíteni a dolgot, így egy olyan eszközt mutatok be, amely modellezési- és különböző 


analízis célokra egyaránt alkalmas. 


Az eszköz, amit választottam, bárki számára hozzáférhető, 
és kellően sokoldalú ahhoz, hogy ne csak prezentációs cé- 
lokra használjuk. 

Ez az eszköz a DANAMICS (Data Network Architecture: Mo- 
delling Concurrent Systems), amely letölthető a [danamics] 
címről (egy demo változat, amely maximum 10 place keze- 
lésére képes). 
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EI A DaNAMICS felülete 


A felső soron szereplő legfontosabb gombok jelentése: 


Gomb Are 








e Place elhelyezése —— 
fái . Időzített illetve időzítés nélküli tranzíció elhe- 
lyezése 
EB Tranzíció elhelyezkedésének módosítása 


. (vízszintes/függőleges) 
Tranzíció típusának megváltoztatása 











ke (időzítetvidőzítés nélküli) 

ma Alhálózat beszúrása. Az alhálózatnak már ké- 
szen kell lennie egy DANAMICS (.bim) fájlban. 

§ Alhálózat megtekintése. a Se 





Él felvétele a hálózatba. A két gomb között az 
a különbség, hogy az előbbi ívelt éleket rajzol, 
míg az utóbbi egyeneseket. 





— 5, ———— Tiltó él beszúrása a hálózatba. 
ES szé Token hozzáadása illetve elvétele egy helyről 
TT "" (place). 





Alkotóelem (place, tranzíció, él stb.) tulajdon- 
ságainak megtekintése. 

A nézet nagyítása/kicsinyítése. 

Alkotóelem mozgatása illetve törlése. 
Kijelölés. 

Tokenek színének változtatása (lásd a színezett 
Petri-hálóknál). 

















Ennyi bevezető után lássunk most egy egyszerű példát, ame- 
lyen keresztül egyrészt egy tervezési feladat megoldását 
igyekszem bemutatni, másrészt természetesen a DaNaMiCS 
működését is. 

Példa: Lift Petri-hálója 

Egy korábbi cikkemben szerepelt egy lift állapotautomatája. 
Most ezt szeretném feleleveníteni azzal az apró módosítás- 
sal, hogy az ajtó nyitását és zárását egyszerűen megállásnak 
nevezzük. 

Első megközelítésben az alábbi módon rajzoljuk fel a lifthez 
tartozó Petri-hálót: 


Nyit2 





B Liftautomata kezdetleges Petri-hálója 


Hogyan hozzuk létre a feni Petri-hálót? A DANAMICS segít- 
ségével először a place-eket helyezzük el: ráklikkelünk a 
,Place elhelyezése" gombra, majd az ablakban tetszőleges 
helyre kattintva elhelyezünk oda egy helyet. Ha többször, 
több helyen kattintunk, természetesen több place kerül elhe- 
lyezésre. Hasonló módon rajzoljuk meg a tranzíciókat is. A 
place-ek és tranzíciók összekötése úgy történik, hogy az ,Él 
felvétele" gombra kattintunk, ezután pedig behúzzuk az élet 
— lenyomva tartott egérgombbal berajzoljuk a megfelelő éle- 
ket (ne feledjük, hogy él csak place-ből tranzícióba, vagy 
tranzícióból place-be futhat!). 4 

Ha egy-egy place-t vagy tranzíciót elhelyezünk, természete- 
sen a rendszer még nem tudja, hogy azokat nem po, p1, p2, 
stb. illetve tO, t1, t2, stb. néven szeretnénk használni. Ne- 
künk azért nem célszerűek ezek az elnevezések, mert bár 
egyediek, egyáltalán nem beszédesek, nem túl sokat árulnak 
el arról, hogy tulajdonképpen mit is akartunk modellezni az 
adott komponenssel. Ezért amint megrajzolunk egy-egy alko- 
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tóelemet vagy alkotóelem-csoportot, érdemes rög- 
tön átnevezni. Ezt mutatja az alábbi ábra: 
























































E Place tulajdonságainak megváltoztatása 


(1) Első lépésként klikkeljünk az ,Alkotóelem tulajdonsá- 
gai" gombra. (Az éppen aktív funkciót megtestesítő 
gomb mindig sárga háttérrel jelenik meg). 

(2) Ezt követően ha bármilyen komponens fölé visszük 
egerünket, a kurzor ,mutató kezecskére" változik. Ha 
ekkor rákattintunk az elemre, egy tulajdonságablak je- 
lenik meg. 

(3) Ezen ablak felső részében néhány beviteli mezőt talál- 
hatunk. Legfelül a komponens nevét állíthatjuk be. Pla- 
ce esetében ezt a tokenszám követi, azaz hogy hány to- 
kent kívánunk elhelyezni az adott helyen a kiinduló ál- 
lapotban. 

A következő mezőben a kapacitást állíthatjuk be (igen, 
ez a — viszonylag új -— alkalmazás képes a kapacitáskor- 
látok kezelésére). 

(4) Az ablak legalsó részében egy kis ábra található az ak- 
tuálisan kijelölt alkotóelemről. Erre kattintgatva az 
elem és a felirat kölcsönös pozícióját állíthatjuk be. 


Ha felrajzoltuk a hálózatot, nyilván szeretnénk látni műkö- 
dés közben. Ehhez először is tokeneket kell elhelyeznünk a 
hálózatban, hiszen ezek adják az egész működés lényegét. 
De mit is jelent esetünkben egy-egy token? 

Ha alaposan megnézzük a hálózatot, a place-ek jelentik a lift 
állapotait, a tranzíciók pedig az állapotátmeneteket. Ennek 
megfelelően a tokenek egy-egy liftet jelölnek, amelyek egy- 
mástól függetlenül mozognak az épületben. Egyliftes rend- 
szert akkor kapunk, ha egyetlen tokent veszünk fel a kiindu- 
lási állapotba. Tegyük ezt a tokent az Idle0-ba, vagyis feltéte- 
lezzük, hogy kezdetben liftünk a földszinten áll. 

Tokent kétféleképp helyezhetünk el. Egyrészt az adott place 
tulajdonságlapján is beállíthatjuk, hogy hány token jelöli azt 
a kezdőállapotban. Másrészt a , Token hozzáadása" funkció 
segítéségével minden egérkattintás eggyel növeli a kijelölt 
place tokenszámát. 

A rendszer működését az alábbiak szerint modellezhetjük: 
Az AnimatePlay menüpontot kiválasztva elindul a szimulá- 
ció. Mivel a Petri-hálók működése nemdeterminisztikus, lé- 
pésről lépésre láthatjuk a tüzelhető tranzíciókat, és választ- 
hatjuk ki, melyik tüzeljen a következő lépésben. Ezáltal mi 
biztosítjuk a nemdeterminisztikusságot, ráadásul a különbö- 
ző tüzelési szekvenciákat így könnyedén, saját igényeinknek 
megfelelően tesztelhetjük. 

Az alábbi ábra azt az állapotot mutatja, amikor a lift az első 
emeleten van, ajtaja pedig zárva: 
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E Szimuláció a DANAMICS segítségével 


Az ábrán színes téglalapok jelölik a tüzelhető tranzíciókat. 
Ha ezek közül valamelyikre ráklikkelünk, következő lépés- 
ként az tüzel, és a Petri-háló átlép a következő állapotba: az 
új tokeneloszlással a tüzelhető tranzíciók halmaza is meg- 
változik. 

Ezzel eljátszogatva láthatjuk, ahogyan a lift egyik emeletről a 
másikra , vándorol", illetve az emeleteken nyitja-zárja ajta- 
ját, stb. Ránézésre a működés , korrektnek" tűnik, azaz a lift 
soha nem kerül holtpontra, illetve soha nem lesz egy liftből 
kettő, ne adj" isten, még több. 

Természetesen ezen intuíciók bizonyíthatók illetve megcá- 
folhatók pontos matematikai módszerekkel. Lássunk most 
ezek közül néhányat! 


Matematikai módszerek a Petri-háló analízisére 


A DaNAMICS a legtöbb analízismódszert támogatja, most 
ezek közül mutatok be néhányat. Az Analysislnvariants me- 
nüpontot kiválasztva egy új ablakot kapunk, amelyben több 
funkciót kijelölhetünk. Válasszuk ki a , Show Incidence Mat- 
rix" sort (a többi egyenlőre nem érdekes számunkra), majd 
nyomjuk le a Calculate gombot. 

Ekkor egy olyan ablak jelenik meg, amely több részből áll, 
valahogy így: 
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E A szomszédsági mátrix 


A szomszédsági mátrix esetünkben azt mutatja, hogy mely 
tranzíciók mely helyekkel szomszédosak (vannak élekkel 
összekötve), és hogy az adott tranzíció a helyhez hány tokent 
ad, vagy vesz el onnan. 

Lássuk, pontosan hogyan is fest a liftautomata szomszédsági 
mátrixa. A könnyebbség kedvéért a mátrixot elláttam a meg- 
felelő fejlécekkel, amelyek azt mutatják, hogy a sorok- illet- 
ve oszlopok mely tranzícióknak/placeknek felelnek meg: 


Tranzíció 





aA 
1 
I 
E 
Sa 
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Hely 


A fenti táblázatban üres cellák jelölik, ha az adott tranzíció 
nincs közvetlen kapcsolatban az adott place-szel. Mivel ese- 
tünkben minden tranzíció súlya 1, a tokenszámok helyett 
(x-1 és -1) csupán az előjeleket tüntettem fel. Így például az 
első oszlop azt mutatja, hogy a Marad2 tranzíció tüzeléskor 
az Idle2 helyhez ad egy tokent, a 2emelet all helyről pedig 
elvesz egyet. 

A táblázat további cellái hasonló módon értelmezhetők. 
Természetesen, ha egy tranzíció nem csak egy tokent vesz el 
egy helyről, illetve ad hozzá helyhez, nem elég az előjeleket 
feltüntetni, a pontos értékeket is szerepeltetni kell a mátrixban. 


A szomszédossági mátrix kitöltése nem túl bonyolult feladat, 
viszont időigényes, hiszen a mátrix mérete a háló méretének 
növekedésével rohamosan nő. Ugyanakkor rendkívüli figyel- 
met is igényel, hiszen a nagy számú mező kitöltése rengeteg 
hibázási lehetőséget tartogat. 


Invariánsok a Petri-hálóban 


A Petri-hálók elemzésében nagy segítséget jelentenek az úgy- 
nevezett invariánsok, melyek a háló különböző jellemzőiből 
számíthatók. Kétféle invariánst különböztetünk meg: a T- (tran- 
zíció-) és a P- (place-) invariánsokat. 

(Az invariánsok olyan jellemzők a matematikában, amelyek 
nem változnak meg akkor sem, ha a kérdéses objektumot min- 
denféle kegyetlen, bár szabályos módosításnak vetem alá. Pél- 
dául a bűvös kockáról a megfelelő invariáns kiszámításával 
azonnal kideríthető, hogy szabályosan tekergetve keverték 
össze, vagy kifeszegették a sarokelemeit és elforgatva rakták 
vissza — a szerk.) 

A T-invariáns olyan tüzelési szekvencia, amely végrehajtása 
nem változtatja meg a Petri-háló tokeneloszlását. A T-invariáns 
létezésével bizonyítható a rendszer ciklikus működése. Ha lé- 
tezik T-invariáns, akkor a rendszer élő, és holtpontmentes. 

A P-invariáns által kijelölt helyeken a tokenek súlyozott össze- 
ge nem változik, azaz a tokenek egy részhalmaza (vagy akár tel- 
jes halmaza) a helyek egy (részjhalmazában kering. A P-invari- 
ánsok által meghatározott helyeken biztosan nem nő a tokenek 
száma (a háló korlátos), és el sem veszik token (a háló élő). 
Ezen invariánsok kézzel is számolhatók a szomszédsági mát- 
rixból, az úgynevezett Martinez-Silva algoritmussal. Ezt az al- 
goritmust használja a DANaMIiCS is (Calculate P-invariants il- 
letve Calculate T-invariants): 














le net is covered by P-Invarianis. 
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E Invariánsok számítása a DANAMICS segítségével 


A Martinez-Silva algoritmus 


Kiindulásként vegyünk fel egy mátrixot (007, amely úgy néz 
ki, hogy leírjuk a szomszédossági mátrixot (W), majd elé írunk 
egy megfelelő méretű (a lift esetében egy 979-es) egységmátri- 
xot. Hogy egyszerűen és látványosan be is tudjam mutatni a 
működését, most egy kicsit félreteszem a liftes példát, helyette 
tekintsük az alábbi Petri-hálót: 


Egyszerű példa 
a Martinez-Silva 
algoritmus 
bemutatására 





Ennek a Petri-hálónak a szomszédsági mátrixa: 


10 ti 
po [a 1 
pr. NEg ei 
piat 


Ez alapján az algoritmus kiinduló mátrixa így írható fel: 


Az algoritmus menete a következő: minden tranzícióra végre- 
hajtunk egy iterációt, amelyben megvizsgáljuk az összes olyan 
place-párt, amelynek egyik tagja bemenő, másik pedig kimenő 
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helye az aktuális tranzíciónak. A t0 esetében például 
ü : pO-p1 és a p0-p2 párokat kell figyelembe venni, 
] mégpedig úgy, hogy mátrixunkba új sorokat hozunk 


létre: 
1 ő 28 ém. 1 po 
07 CAO áá pi 
öz kőr tő d p2 
it m..ú ú úl p0-Ri 
Tt 0 1 0 Öl pöspZ 


Hogyan jönnek létre ezek az új sorok? Roppant egyszerűen: az 
adott place-eknek megfelelő eredeti sorokban szereplő értéke- 
ket mezőről mezőre összeadjuk. (A fenti mátrixban például a 
felső két sor összege a bekeretezett 4. sor.) 

Ezeket az új sorokat felvesszük minden, a fenti feltételeknek 
megfelelő place-párra. Amikor ezzel készen vagyunk, a lépés 
során figyelembe vett place-ek sorait elhagyjuk a mátrixból: 


4 KIÜT 
mel kak b 


Az algoritmust addig folytatjuk, amíg nem fogynak el az ere- 
deti place-sorok, vagy amíg nem mentünk végig minden tran- 
zíción. 

Az algoritmus végén egyszerűen kiolvashatjuk a P-invariánso- 
kat: p0-p1 és pO-p2. 


p0- pl 
pO - p2 


E rövid kitérő után térjünk vissza a liftautomatához, és lássuk, 
mit is jelent pontosan a kapott eredmény? A P-invariáns egy 
oszlopvektor, amelynek minden sora (eleme) egy-egy helyhez 
tartozik, azaz: 


Idle2 

Idle1 

Idleo 
2Zemelet all 
Temelet all 
Földszint all 
2emeleten 
Temeleten 
Földszinten 


sk dl ál ák aatk sáó sál ák iss 


Ez azt jelenti, hogy minden egyetlen P-invariáns van, ebben 
minden place egyszeresen szerepel, azaz a keringő token se- 
hol nem tűnik el, és sehol nem , osztódik". 

A T-invariáns mezőben egy mátrixot találunk. Sorainak itt a 
tranzíciók felelnek meg, oszlopai pedig egy-egy T-invariánst je- 
lölnek. A kapott mátrix a lift esetében így néz ki: 


t 


Marad2 
Ebred2 
Marad1 
Ebred1 
Marado 
Ebredo 
ZarOo 

Nyito 

Zar1 

Nyiti 

Zar2 

Nyit2 
Lemegy 21 
Felmegy 12 
Lemegy 10 
Felmegy 01 


SOCGOOGOOGGC OCGCOCOOOOGOG- 
EGO OCOCO- OO 
DBBGGOGCDGDGCGGGGOS AG OG 
BE GAGE a Ge 6 e 
DBDBOEGDGD DG S5SDDESGGeEeE E 
GOGO AA MD EeEBGBEAE MGO 
Gas aÜMmáT BG GBG RAG OG 
a DaRaR RG GAáG GE E 





Mit is jelent pontosan a fenti mátrix? Lássuk az első oszlopát: a 
Marad2 és az Ebred2 tranzíciót tartalmazza, azaz ha ezek a 
tranzíciók egymás után egy-egy alkalommal tüzelnek, az nem 
változtat a rendszer tokeneloszlásán. (Természetesen itt a mi- 
nimális T-invariánsokat számoljuk, hiszen ennél hosszabb 
szekvenciák is létezhetnek [pl. az Ebredo, ZarO, NyitO, Ma- 
rado], de ezek mindig elemi T-invariánsokból állnak össze. 


Elérhetőség 


A DanaMiCS segítségével a Petri-háló egyéb tulajdonságai is 
könnyedén vizsgálhatók. Az Analysis 2 Coverability Graph 
menüpont segítségével (vagy a már megnyitott Results Vie- 
wer megfelelő fülének kiválasztásával) egy újabb listát ka- 
punk a meghatározható jellemzőkről. A Calculate gombra 
kattintva egy ilyen ablak jelenik meg: 






























































E zlol2i 
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FA iwariant 
e netis Live. 
e netis Bounded. 
alinformation 
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e net is Safe. 
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E Elérhetőség vizsgálata a DANAMICS segítségével 


tt 43: §.3 


A színezett Petri-hálók 


A fent bemutatott analíziseken kívül egyéb vizsgálatokat is 
végezhetünk a DaNAMICS segítségével, ezekre azonban 
most nem térnék ki. Ehelyett a színezett Petri-hálókról ejte- 
nék néhány szót. 

Eddig a tokeneket egyszerűen felvettük a hálóba, nem tet- 
tünk különbséget közöttük. (Nem volt fontos, hogy melyik lift 
van az adott emeleten, az számított csupán, hogy jöjjön va- 
lamelyik lift.) Ez azonban az esetek jelentős részében nem 
elég, szükségünk van arra, hogy különböző típusú tokeneket 
hozzunk létre, amelyek vagy egyes példányokat jelölnek, 
vagy egy-egy csoportot (például egyfajta tokenek a lányokat, 
másmilyenek a fiúkat). 

Több megoldás létezhet a tokenek megkülönböztetésére, 
például a különböző típusokat jelölhetnénk különböző alakú 
jelekkel (például pöttyökkel, háromszögekkel, négyzetekkel, 
stb.), sokkal átláthatóbb és esztétikusabb megoldás azonban, 
ha a tokeneket színükkel különböztetjük meg egymástól. Az 
eddig egyformán fekete tokenek helyett színes tokeneket raj- 
zolunk, és a különböző színű tokenek szolgálnak a megkü- 
lönböztetésre. Így például már azt is meg tudjuk mondani, 
hogy melyik lift tartózkodik egy-egy adott helyen, nemcsak 
azt, hogy van-e ott lift (kétszínű nyomtatásban minden tehén 
fekete — a szerk.) 


Felmegy. 12 


Felmegy. 01 





EB Az egyes liftek megkülönböztetése színezett tokenek 
segítségével 


A fenti ábra például azt az állapotot (tokeneloszlást) 
mutatja, amikor a piros lift a földszinten van nyuga- 
lomban, a zöld az első emeleten mozog (felfelé 
vagy lefelé halad, illetve épp most nyit majd ajtót, 
vagy most zárta azt), a kék pedig a második emele- 
ten áll nyitott ajtókkal. Annak kezelése, hogy az egyes színek 
a valóságban mely lifteket jelölik, a mi felelősségünk 
(ugyanúgy, ahogyan egy programkódban is nekünk kell tud- 
nunk, hogy egy adott változó a valóságban minek felel meg). 


Remélem, mindenki érdeklődését sikerült felkeltenem a Pet- 
ri-hálók iránt. A piacon természetesen sok olyan eszköz ta- 
lálható még, amely segíti a modellezést és az analizálást. A 
következő hónapokban már nem ezekkel foglalkozom (bí- 
zom abban, hogy mindenkinek sikerült kellő kiindulást biz- 
tosítanom így is), hanem újabb vizekre evezem. 


Molnár Ágnes 
agi€harpia.homeip.net 
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IéS2: 


Internet Information Services 6.0.- 


BE 


Internet Information 
. Services 5.Ő 


II. rész: A Windows 2003 Server webkiszol- 


gálójának újdonságai 


Az előző részben megismertük az IIS 6.0 webkiszolgálójának új belső felépítését. Most tovább ismer- 
kedünk a webkiszolgálóval és terítékre kerül az FTP szolgáltatás is. 


Az IIS 5 Isolation Mode 


Az előző számban leírt, alapértelmezett Worker Process Isola- 
tion Mode mellett az IIS6 kompatibilitási okokból képes az 
úgynevezett ,IIS 5 Isolation Mode"-ban is futni. A kiszolgáló il- 
letve a webalkalmazások ilyenkor az IIS 5 felépítéséhez na- 
gyon hasonlóan működnek. 


T Internet Informatión Servi 
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S WebSte ] Performance ] ISAPIFíters ] HomeDrectory ]) Documents ] 

4 Internet Information Se Directory Security HTTP Headers Custom Errors Service 

EJ. újd SERVER2003 (local 

(1 .J Application Poo 
EJ Web Stes 

80 Defaut we 

.J Web Service Ex 


Isolation mode — 





Az IIS 5 Isolation Mode a webkiszolgálók gyökerén kapcsolha- 
tó be, hatása a kiszolgáló minden virtuális webkiszolgálójára 
érvényes! 

A beállítás módosítása után a webszolgáltatások újraindulnak, 
a felhasználói felületről pedig eltűnnek az Application Pool-ok, 
helyettük a webalkalmazásoknál az IIS5-ben már jók megszo- 
kott, és az előző részben részletesebben is leírt , Application 
Protection" mezőben állíthatjuk be a , Low (/IS Process)" , ,Me- 
dium (Pooled) , illetve , High (Isolated)" értékeket. 

A http.sys és a WAS természetesen ebben az üzemmódban is 
megmarad, csak a w3wp.exe-k szerepét veszi át az inetinfo.e- 
xe és a dilhost.exe. 

Összehasonlításul álljon itt egy táblázat a különböző funkciók- 
ról és az őket megvalósító komponensekről, az IIS különböző 
üzemmódjaiban: 





édi) LES] DN] LIGA] 
(Windows 2000) (1 KIE) (Worker Process 
Isolation Mode) Isolation Mode) 
IIS metabase Inetinfo.exe Inetinfo.exe Inetinfo.exe 
(bináris) (XML) (XML) 
http.sys - WAS WAS 
konfiguráció 
Worker Process - - W3wp.exe 
WP menedzsment - - WAS 
In-Process Inetinfo.exe Inetinfo.exe W3wp.exe 
ISAPI alk. 





Out-of-Process Dllhost.exe Dllhost.exe - 

ISAPI alk. 

ISAPI szűrők Inetinfo.exe Inetinfo.exe W3wp.exe 

HTTP protokoll!  Inetinfo.exe http.sys http.sys 
(winsock) 

FTP, SMTP, Inetinfo.exe Inetinfo.exe Inetinfo.exe 


NNTP 


Az IIS6 alapértelmezett üzemmódját az dönti el, hogy a kiszol- 
gálót hogyan telepítettük: 
A Tiszta telepítésnél: Worker Process Isolation Mode 
A Az 1IS6 korábbi (béta) verziójának frissítésénél: megma- 
rad a frissítés előtt beállított üzemmód 
ma IIS4, IIS5-ről történő frissítéskor: IIS 5 Isolation Mode 


Az ASP.NET Process Model és az IIS6 


Az ASP.NET programozók jól tudják, hogy az ASP.NET saját 
processzmodellt is tartalmaz. Amikor az ASP.NET a webkiszol- 
gáló ,IIS 5 Isolation Mode"-jában fut, akkor a saját processz- 
modelljét és beállításait használja (a machine.config fájlból). 
Amikor azonban a webkiszolgáló az új Working Process Isola- 
tion Mode-ban fut, az ASP.NET letiltja a saját processzmodell- 
jét és ő is aláveti magát a WAS akaratának. 

Ez önmagában általában nem jelent túl nagy gondot, mert az 
ASP.NET processzmodellje sokban hasonlít az IIS6-ban megva- 
lósítotthoz (talán nem véletlenül). Azonban, a Working Process 
Isolation Mode két beállítás kivételével figyelmen kívül 
hagyja az ASP.NET machine.config fájl tartalmát, kivéve a 
maxlOThreads és a maxworkerThreads értékeket. Minden más 
itt megadott beállítás érvénytelen marad, ezért szükség lehet 
arra, hogy azokat kézzel ,másoljuk" át az IIS (egészen ponto- 
san a megfelelő Application Pool) beállításai közé. 


Az IIS 6.0 és a biztonság 


Tanulva az elmúlt évek — sokszor nagyon is jogos — kritikáiból, 
végre az IIS programozói is csatlakoztak a ,minden tilos, kivé- 
ve amit engedélyezünk" felfogáshoz. (Emlékeztetőül: az IIS 
5.0 még a , mindent szabad, kivéve amit tiltunk" elv jegyében 
működött, és ezt a hozzáállást használják ki a mai napig is az 
IIS-eken terjedő férgek és egyéb kártevők). Egy frissen telepí- 
tett IIS 6.0 csak és kizárólag statikus tartalom (.htm! oldalak, 
képek, egyebek) kiszolgálására alkalmas, minden más extra 
szolgáltatást (például az ASP-t, ASP.NET-et, WebDA V-ot, 


FrontPage Server Extensionst) a telepítés után külön kell enge- 
délyeznünk! Amíg ezt meg nem tesszük, az IIS az ilyen jelle- 
gű erőforrásokra utaló kérésekre HTTP 404-es (Not Found) hi- 
bát küld vissza, nagyon helyesen. 

Az engedélyezhető webkiszolgáló-bővítményeket (például az 
ASP motor is ez), az IIS Managerben, a Web Service Extensions 
alatt találjuk: 





(3 Internet Information Services (IIS) Manager 


— Action Mew Window Help 


lit ABIRIAI) mun 


4 Internet Information Services 
9 SERVER2003 (local computer) 





















7 AIlUnknown ISAPI Extensions 













jr AFEREGÉGA EGG 77 AllUnknown CGI Extensions Prohibíted 
) al e B TGjús SÁNSEPI Pr iz 
Hepi köt 15] Internet Data Connector Prohibited 
3. 68) Default web Sze (3). Server Side Includes Prohibited 

.J Web Service Extensions [5 
(81 Webpav Prohibited 






B Vasszigor: a bővítmények alapértelmezett beállításai 


Láthatjuk, hogy a telepítés után rendelkezésre álló bővítmé- 
nyek mindegyike tiltott (Prohibited). Lássuk, melyik mire is 
való: 

A AII Unknown ISAPI Extensions: minden olyan ISAPI 
bővítmény (azaz bizonyos típusú erőforrásokhoz ren- 
delt ,motor", általában .dil), ami a listában külön nem 
szerepel 

A AII Unknown CGI Extensions: minden olyan külső, 
webkiszolgálóból futtatható alkalmazás (.exe), ami a 
listában külön nem szerepel. 


A fenti két opció általános beállítás, a következő négy azonban 
már konkrét telepített és engedélyezhető bővítményt takar. 
Ezeknél a tiltáslengedélyezés mellett egy tulajdonságlapot is 
találunk, ahol megtekinthetjük a bővítményhez tartozó erőfor- 
rásokat (.dII-eket), és akár egyenként is engedélyezhetjük vagy 
tilthatjuk őket! 


H Active Server Pages: .asp alkalmazások futtatásához 
szükséges bővítmény (igényli például az Exchange 
2000 és a Certificate Services) — asp.dll 

HI WebDAV: a kiszolgálón megosztott webes mappák ír- 
ható-olvasható hozzáféréséhez használt protokoll — 
httpext.dil 

A Server Side Includes: Kiszolgálóoldali SSI direktívák 
(exec, Hconfig, stb.) végrehajtását vezérlő bővítmény 
— ssinc.diI. Hacsak nincs rá kifejezetten szükségünk (ál- 
talában .shtm illetve .shtml fájlok kezeléséhez kell), 
hagyjuk tiltva! A SSI funkciókat ASP segítségével 10090- 
ban meg lehet valósítani. 

TA Internet Data Connector: .idc fájlok végrehajtását 
végző komponens, webes ODBC adatbázis-hozzáfé- 
réshez — httpodbc.diI. Funkcióját az ASP-ben használt 
adatbáziskezelő komponensek már szinte teljesen ki- 
váltották. Kompatibilitási okokból maradt bennt, ha 
nincs rá szükségünk, ne engedélyezzük! 


További komponensek telepítése 


Feltűnhetett, hogy a fenti listából sok minden hiányzik. Nincs 
ott például a Microsoft egyik legfontosabb zászlóshajója, az 
ASP.NET, de a FrontPage Server Extensions bővítményeket sem 
látjuk sehol. Ezeket külön kell telepítenünk, mielőtt engedé- 
lyezhetnénk őket. Ehhez indítsuk el a Control Panel 2 Add or 





Remove Programs 2 Add/Remove Windows Com- mg) 
ponents varázslót! ha) 


Az Internet Information Services-t és a kapcsolódó 
szolgáltatásokat az , Application Server" csoportban 
találjuk: 


Application Server XX] 





To add or remove a component, click the check box. A shaded box means that only part 
of the component will be installed. To see what s included in a component, click Details, 


52 Tfh Application Server Console 
CI $zASP.NET 0.0 MB 
IZ ÉB Enable network COM: access 
Z1 EjEnable network DTC access 










Description: IIS Inciudes web, FTP, SMTP, and NNTP support, along with support 
for FrontPage Server Extensions and Active Server Pages (ASP). 


Details... ] 
Camel] 


Total disk space regured: 0.0 MB 
Space available on disk: 2564.1 MB 





E Az Internet Information Services az Application Server 
szolgáltatáscsoport része lett. Ugyanitt kapcsolható be 
az ASP.NET-támogatás is 


Az ASP.NET telepítéséhez tegyünk mellé pipát; az IIS kompo- 
nenseinek (például a FrontPage Server Extensions) kiválasztásá- 
hoz pedig jelöljük ki az IIS-t és kattintsunk a , Details" gombra: 


ata ee ukaasát] XI 


To add or remove a component, click the check box. A shaded box means that only part 

of the component will be installed. To see whats included in a component, click Details. 
omponents of Intemet Information Services (IS): 

TC £ Background Intelígent Transfer Service (BITS) Server Extensions. 0.2MB 2 

2 2 Common Files 

I e. File Tianálát Protocol E! P) Service 






Ej fun ÜTEEeT EE sTTEST TE Manager 1.3 MB 
OI €éőintemet Ptinting 0.0 MB 
CI €3NNTP Service 12m8 zl 
Description: Enables authoring and administration of websítes with Microsoft 
FrontPage and Visual InterDev 


Total disk space reguired: 0.0 MB 
Space available on disk: 2564.1 MB 


Detals 
Ezt 





E Az Internet Information Services telepíthető összetevői 


Miután az ASP.NET és a FrontPage 2002 Server Extensions fel- 
települt, az IIS konzolban a webkiszolgáló bővítményei között 
(rögtön engedélyezve) megtaláljuk majd: 
HA ASP.NET v1.1.4322 — aspnet isapi.dil 
HA FrontPage Server Extensions 2002 - admin.dll, 
fpadmdll.diI, author.diI, fpcount.exe, shtml.dil 


Természetesen a beállítások között minden fájlnév a teljes elé- 
rési utat tartalmazza, azaz a FrontPage Server Extensions enge- 
délyezése nem jelenti azt, hogy bármilyen más admin.dll-t is 
engedélyeznénk! 


XML MetaBase 


A MetaBase az Internet Information Services saját konfigurá- 
ciós adatbázisa. Ez az adatbázis tárol minden olyan informá- 
ciót, ami az IIS működéséhez szükséges (az adminisztratív esz- 
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18 közökkel is többnyire ebben szerkesztgetünk, az IIS 


beállításainak mentése-visszaállítása pedig gyakorla- 

ül ! — tilag a MetaBase mentését is visszaállítását jelenti). 

l 1IS5-ig ez az adatbázis egy speciális felépítésű biná- 

ris fájl volt (metabase.bin); szerkesztéséhez külön 

eszközöket (MetaEdit) és scripteket kaptunk. Ilyen scripteket 
egyébként magunk is írhatunk. 





B MetaBase.xmi - Notepad 
Ele Edt Format View Hebp 
Ssmtpsve/Info" 
LogModuleListe"NCSA Common Log File Format, ODBC Loggin 
MO-SERVER CAPABILITIES5 "80831 
MD. SERVER PLATFORM-"1 
Major1IsversfonNumber e 6 
Minor1IsversionNumber 2"0" 





z 
e/1ISSMTPINfOZ 
jeriIswebservice Location e5/LMm/w3svci 
ATTOwKeepalives "TRUE" 
Anonymoususer Names "IUSR. SERVER20037 
ANONYMOUSUSEr Pass a 4963446270000000220000004000000055b9. 
Appa! lowciientDebugz "FALSE" 
APPATTowoebuggingz "FALSE" 
AppPoolId-"Def aultappPool" 
ApplicatjonDependenciese"Active Server Pages;ASP 





Internet Data Connector ; HTTPODBC 

Server side Inciudes;SSINC 

WebDAV; WEBDAV 

ASP.NET v1.1.4322;ASP.NET v1.1.4322 ; 

FrontPage Server Extensions;FPSE, ASP, Indexings 
ASPAllowoutofProccomponentsz"TRUE" 
ASPATTowSessjonStates TRUE" 


AspappServiceFlagsz"0 


E Az IIS6 MetaBase részlete 


Az IIS6 MetaBase legfőbb újdonsága, hogy az adatbázis immár 
nem bináris, hanem XML formátumban található a lemezen. 
Ennek legnagyobb előnye, hogy ember által olvasható (már 
amennyire egy hatvan kilobájtos XML dokumentum az), és 
nincs akadálya annak, hogy a beállításokat akár egy Notepad 
segítségével módosítsuk a MetaBase belsejében. A fájlt egyéb- 
ként a 


NWINDOWSYSystem321inetsrvIMetaBase.xml 


útvonalon találjuk meg. Az inetinfo.exe ezt minden indulása- 
kor a memóriába tölti és onnan dolgozik az adatokkal. Éppen 
ezért, ha a beállításokon valamelyik grafikus eszközzel módo- 
sítunk, az először csak a memóriában történik meg, a lemezre 
pedig csak a kiszolgáló leállásakor kerül. Ha egy opciót szeret- 
nénk rögtön a beállítás után a MetaBase.xml fájlban látni, az 
IIS Manager-ben kattintsunk jobb gombbal a webkiszolgáló ne- 
vére, majd a menüből válasszuk az All Tasks 2 Save Configu- 
ration to Disk parancsot! 

Ha a kiszolgáló tulajdonságai között engedélyezzük az ,Enab- 
le Direct Metabase Edit" opciót, az IIS futás közben észleli a 
MetaBase esetleges változtatásait és azonnal újra betölti azt. 
Az új MetaBase egyébként továbbra is használható minden 
olyan eszközzel, scripttel vagy technológiával (például ADSI 
vagy WMI), amivel a korábbi változatok. Az alapértelmezett 
beállítás szerint minden változtatás előtt a MetaBase-ből ké- 
szül egy biztonsági másolat a 


NWINDOWSYsystem32VinetsrvlHistoryN 


mappába, így a webkiszolgáló bármelyik állapota könnyen 
visszaállítható. 








SERYER2003 (local computer) Properties 


Internet Information Services ] 
TT Enebie Direct Metabase Edit 


Allows you to edit the IIS metabase configuration file while IIS is 
running, 








[7UTF-8 Logging 


állovvs TIS to write log entries using UTF-8B encoding instead of local 
code page. 


TT Encode Web logs in UTF-8 








E A webkiszolgáló globális beállításai 


Webnaplók UTF-8 formátumban 


Ugyanitt, a webkiszolgáló globális tulajdonságai között kap- 
csolhatjuk be a webnaplók UTF-8 formátumát. Ez a formátum 
képes a webkiszolgálóhoz beérkező Unicode kódolású kéré- 
sek naplózását is. Ennek a funkciónak nálunk leginkább csak 
hibakeresési szempontjai lesznek, de a távol-keleti világban 
ennek nagyobb jelentősége lesz. 


Az FTP kiszolgáló újdonságai 
Az újrakezdhető le- és feltöltések mellett (ami már a Windows 
2000-ben megjelent), az FTP szolgáltatásnak két újdonsága 
van (halkan jegyzem meg, hogy volt, ahol ezek az ,újdonsá- 
gok" évtizedekkel ezelőtt természetesen voltak...): 
A Server-to-Server FTP: adatmásolás két FTP kiszolgáló 
között úgy, hogy az adat az ügyfélhez nem jut el, csak 
a kiszolgálók között mozog 
A FTP User Isolation: a felhasználók gyökérkönyvtárainak 
beállítása után a felhasználó azt semmilyen módon 
nem hagyhatja el (a saját könyvtárát látja az FTP kiszol- 
gáló gyökérkönyvtárának). 


Server-to-Server FTP 


A szolgáltatás engedélyezéséhez két registry-értéket kell beállí- 
tanunk: 





Ezután az FTP kiszolgáló engedélyezni fogja a kiszolgálók kö- 
zötti fájlátvitelt. Nagyon fontos, hogy az EnablePasvConnF- 
rom3rdiP engedélyezésével biztonsági rést ütünk a pajzson, 
ezért internetes környezetben ennek beállítása nem javasolt. 


FTP User Isolation 


A felhasználónként beállítható gyökérkönyvtár régóta jogos 
igény a Windows FTP szolgáltatásában. Eddig (valamint az 
IIS6-ban az alapértelmezett beállítások mellett) legfeljebb 
annyit tudtunk elérni, hogy az FTP gyökérkönyvtárában (Wnet- 
Pub WTPRoof) létrehoztunk egy, a felhasználó nevével mege- 
gyező mappát (vagy virtuális könyvtárat). Ekkor, ha a felhasz- 
náló bejelentkezett, alapértelmezésben a nevének megfelelő 
könyvtárba került (anonymous felhasználóhoz értelemszerűen 
az anonymous nevű könyvtárat kellett létrehozni). Mivel azon- 
ban a felhasználónak a valódi gyökérkönyvtárhoz (azaz a saját 
könyvtárának szülőkönyvtárához) legalább browse joggal kell 


rendelkeznie, a cd.. parancs segítségével a saját mappáját el- 
hagyva kiléphetett oda. 

Az FTP User Isolation Mode ezt segít elkerülni. Ha bekapcsol- 
juk, a felhasználó a saját könyvtárát az FTP kiszolgáló , gyökeré- 
nek" látja, azt tehát nem tudja elhagyni. Az FTP User Isolation 
Mode virtuális FTP kiszolgálónként kapcsolható be (vállalkozó 
kedvű olvasóink máris elkezdhetik keresgélni a MetaBase-ben 
az lisFtpServer elem UserlsolationMode attribútumát),. Nem 
biztos, hogy elsőre sikerül megtalálni, ugyanis az üzemmód 
csak a virtuális FTP kiszolgáló létrehozásakor határozható 
meg, és annak későbbi módosítására sincs mód (a Default FTP 
Site pedig nem támogatja az FTP User Isolation módo. 

A dolog kipróbálásához tehát egy új virtuális FTP kiszolgálót 
kell létrehoznunk. Az IIS Manager-ben az FTP Sites-re kattintva 
válasszuk a New... 2 FTP Site... parancsot, adjunk meg egy 


nevet, majd válasszuk ki a használni kívánt IP-címet és portot. 
Ezután a következő beállítópanellel találkozunk: 






FTP Site Creation Wizard 


FTP User Isolation 
Restrict FTP users to their own FTP home dírectory. 














lsz ezejezotkesemáttegl er száek ás tás tsázzzzteabz 


user on this FTP síte. 

kel tedet test cannot change the user isolation option after creating this FTP. 
áfa iezdábont bant TP ter oloten hihe IS podet documertalon belae 

Tószóg en koláen 





C Isolate users 
(Users must be assigned an FTP home directory within the root of this FTP site.) 


C Isolate users using Active Directory 
(Users must be assigned an FTP home dírectory that is configured using their Active 


Directory user account.) 
eu 








B Az FTP User Isolation beállítás csak a virtuális FTP ki- 
szolgáló létrehozásakor határozható meg 


Itt három lehetőségünk van: 

HA Do not isolate users: a felhasználókat nem izoláljuk (az 
NTFS jogosultságok ettől függetlenül természetesen ér- 
vényesek!!!) 

TA Isolate users: a helyi és tartományi felhasználók izolá- 
lása 

TA Isolate users using Active Directory: a helyi és tarto- 
mányi felhasználók izolálása az Active Directory-ban 
tárolt információk segítségével. Ekkor meg kell még ad- 
nunk egy felhasználónevet, aminek segítségével az IIS 
az Active Directory-ban keresgélni tud majd, valamint 
egy alapértelmezett tartománynevet arra az esetre, ha a 
felhasználó tartománynév nélkül jelentkezne be. 


Felhasználók izolálása Active Directory nélkül 


Ha nincs Active Directory, a felhasználókat egyszerű könyvtár- 
struktúra segítségével irányítgatjuk. 





E Az FTPRoot alatti könyvtárstruktúra Active Directory 
nélküli FTP User Isolation esetén 


tech.net B ETK1IÉŰ vw i 


A teendő az, hogy az FTPRoot alatt hozzuk létre a 
következő alkönyvtárakat: 


AA LocaluUser: a helyi felhasználói könyvtárainak L — 
gyökere 

LocalUserwpublic: az anonymous FTP felhasználó 
könyvtára 

LocalUservefelhasználóz: a helyi cfelhasználóz nevű 
felhasználó könyvtára (itt: teszt) 

cdomainnév3: a cdomainnév3 tartomány felhasználói 
könyvtárainak gyökere (a tartomány neve ebben a pél- 
dában FALATRAX2003 volt) 
cdomainnévotcfelhasználóz: a cdomainnév: tarto- 
mány cfelhasználós felhasználójának könyvtára (itt 
FALATRAX2003 Weszt) 
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Természetesen a listába akármennyi tartományt felvehetünk. 
Figyeljünk arra hogy ha — bár biztonsági szempontból nem 
szerencsés — az FTP kiszolgáló tartományvezérlőn fut, akkor 
mindenképpen a cdomainnévstcfelhasználóz formátumot 
kell használnunk. 


A felhasználók izolálása az Active Directory segítségével 


Ebben az üzemmódban a felhasználó gyökérkönyvtárát a fel- 
használó Active Directory-objektumában tárolt adatok hatá- 
rozzák meg. Ehhez a Windows 2003 Active Directory-sémá- 
ban a felhasználói fiók objektuma két új jellemzőt kapott: ezek 
az msIIS-FTPRoot és az msIIS-FTPDir. A mezők jelentése: 


A FTPRoot: a felhasználó könyvtárának elérési útja (lehet 
UNC útvonal is) 
TA FTPDIir: a felhasználó könyvtárának neve 


A könyvtár teljes nevét az FTPRoot és az FTPDir mezők 
sÖsszeolvasása" adja. Az alapértelmezett rendszergazdai felü- 
leten ezek a mezők nem láthatók, de az IIS-hez adott iisftp.vbs 
script segítségével lekérdezhetők illetve beállíthatók. Példák a 
mezők beállítására és lekérdezésére: 
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MindOTUS 


Brightstor ARLSerue v9 for 


Foglalt állományok és alkalmazásszerverek 


mentése 


Az adatmentés teljességének feltétele a mentendő adatok állományszintű változatlansága. Ez a feltétel 
feloldandó érdekütközéshez vezet a gazdaalkalmazás és mentőmegoldás között. 


A Computer Associates Brightstor ARCserve nevű adatmentő és 
-helyreállító szoftverterméke a rendhagyó számozású 2000-es 
után a 9-es verziónál tart. Néhány kevésbé elterjedt operációs 
rendszertől és alkalmazástól eltekintve tetszőleges, az eredeti 
gyártó által még támogatott operációs rendszer illetve alkalma- 
záskiszolgáló adatainak mentésére, helyreállítására alkalmas. 
A BrightStor ARCserve Backup v9 for Windows, Win- 
dowsNT/2000/XP/2003-környezetben telepíthető: a telepítés 
egylépéses, gyors, kevés felhasználói beavatkozást igényel. 

A szerver- és kliensoldali komponensek a megfelelő jogosultsá- 
gok birtokában a helyi és távoli gép(ekJre is telepíthetők. A te- 
lepítőprogram felismeri a telepíthető összetevőket, és ajánlatot 
tesz a telepítésükre. 


Atea E 


Select Products 
Please select the products to install. 


xi 



















Servetless Backup Option 
Image Option 
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48) Tape Library Option 
Optical Library Option 
Storage Area Network Option 











E Telepítés egy lépésben 


A mentési rendszer 


Egy mentési rendszer nélkülözhetetlen összetevői a követ- 
kezők: 

TA adatforrás 

AA feladatütemező és -kiosztó 

TA adattároló. 


Bár a feladatütemező és- kiosztó szerepe nagyon fontos a men- 
tési rendszerben, ez a cikk csak az adatforgalom két végével, 
az adatforrással és adattárolóval foglalkozik. 

Hálózati környezetben az adatforrást kétféleképpen érhetjük 
el. A mentőszerver gazdagépe által ismert valamennyi álllo- 
mánymegosztási protokollt (pl. SMB, NFS, NCP(IPX/SPX)) fel- 
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használhatjuk távoli gépen levő, de a mentőszerveren helyi ál- 
lományként látszó állomány mentésére. 

A javasolt megoldásnál célalkalmazást, ún. mentőügynököt te- 
lepítünk a mentendő adatokat szolgáltató számítógépre. 


A mentőügynök 


A mentőügynök, fajtájától függően alkalmas lehet a rendszer- 
és felhasználói állományok, vagy a támogatott alkalmazásszer- 
verek állományainak on-line, azaz üzem közbeni mentésére. 
Az on-line mentés során a mentendő szerver átmeneti teljesít- 
ménycsökkenés árán, de folyamatosan kiszolgálja a felhaszná- 
lói igényeket is. Az operációs-rendszert mentő ügynök (Uni- 
versal Client Agent) számos feladatot lát el: fellapozza a gaz- 
dagép meghajtóit/köteteit és állományrendszerét, rendszerleíró 
állományait az esetleges fürtözést leíró állományokkal együtt, 
és ha van, az Active Directoryt, illetve Netware-mentés eseté- 
ben a Novell címtárat. 

Ha telepítettük az egylépéses rendszervisszaállítási opciót 
(Disaster Recovery Option) is, a hálózati beállításokat és a há- 
lózatikártya-meghajtót, továbbá a partíciós adatokat is össze- 
gyűjti. A mentésre kijelölt állományokat valós időben tömörít- 
ve küldi el a mentőszervernek: ezzel a mentendő adatok tömö- 
ríthetőségével arányosan időt és sávszélességet takarít meg. 


Foglalt állományok 


A mentőrendszer tervezésénél kiválasztjuk azt az időszakot 
(Backup Window), amelyben a mentendő rendszer terheletlen. 
Ebben az időtartományban a rendszererőforrások szinte korlá- 
tozás nélkül használhatók mentési célokra, a mentendő állo- 
mányok a mentés szempontjából ideális, nyugalmi állapotban 
vannak. 

A mentés teljességének feltétele a mentendő adatok állomány- 
szintű változatlansága, azaz annak szavatolása, hogy egy adott 
állomány a mentés sikeres befejezéséig nem fog megváltozni. 
A folyamatos üzemű számítógépes környezetben lerövidül, sőt 
adott esetben teljesen el is tűnik a nyugalmi időszak, legfeljebb 
a terhelés napszak-, vagy más jellemzőtől függő átmeneti csök- 
kenéséről beszélhetünk. Ilyen körülmények között nem szava- 
tolható a mentendő állományok változatlansága, tehát a gaz- 
da- és a mentőalkalmazás érdekei ütköznek. 

Az ütközést az ú.n. nyitottállomány-ügynök (Open File Agent, 
OFA) oldja fel. 

Az OFA rendszermag-szinten működik, a mentőszoftver felől 
érkező kéréseket szolgálja ki. Az OFA mindaddig passzív, amíg 
egy bizonyos állomány mentésére nem érkezik kérés, és csak 


akkor éled fel, ha a mentendő állomány a mentés kezdetének 
pillanatában foglalt. Ekkor elindul egy időzítő, amely egy olyan 
öt másodperces intervallumot keres, amelyben az állomány ál- 
lományrendszerbeli megjelenítése változatlan. Előfordulhat, 
hogy a memóriában időközben már megváltozott az állomány, 
de ezt a változást nem lehet menteni, emiatt figyelmen kívül 
hagyja. Ha záros határidőn belül sikerül egy nyugalmi perió- 
dust találnia, ,pillanatképet" készít az állományról. Ez a ,pilla- 
natkép" más hasonló megoldásoktól eltérően nem az eredeti 
állomány másolatát jelenti, hanem azt a rögzítési tevékenysé- 
get, melynek során a mentés ideje alatt megváltoztatandó állo- 
mányrészek eredeti tartalma egy átmeneti pufferbe, az ún. Pre- 
view File-ba kerül. Amikor a mentési folyamat eléri az időköz- 
ben megváltozott részt, az OFA az eredeti adatokat küldi a puf- 
ferből. 

Azokat az alkalmazáskiszolgálókat, amelyekhez a BrightStor 
ARCserve v9 nem rendelkezik külön mentőügynökkel, szintén 
a nyitottállomány-ügynökkel menthetjük. Ha ezek az alkalma- 
zások több változó tartalmú állományból állnak, valamennyi 
érintett állományt egyidejűleg kell elmenteni. Ezt a feltételt az 
OFA úgy teljesíti, hogy az alkalmazáshoz tartozó állománycso- 
portra végez foglaltságvizsgálatot, és minden egyes állomány 
változásait rögzíti. 








E A nyitott állományok mentése 


(1) Az állomány a mentés kezdetén nyitott 

(2) Az OFA nyugalmi állapotra vár, majd ,fényképez" 
(3) Az állomány egy része megváltozik 

(4) Az OFA a változás előtti állapotot eltárolja 

(5) A mentés eredeti állapot szerint történik 


Microsoft Exchange-kiszolgáló mentése 


A Microsoft Exchange-hez kifejlesztett mentőügynök alapfela- 
data az Exchange levelező-adatbázis (Information Store) valós- 
idejű mentése, illetve Exchange 2000 esetében még a Key Ma- 
nagement Service- és a Site Replication Service-adatbázis, Ex- 
change 5.5 esetében pedig a címtár mentése is. Natív. Win- 
dows 2000-es környezetben az Active Directoryt a rendszer- 
mentő ügynökkel mentjük. 

Az Exchange-ügynök további szolgáltatása a felhasználói 
postafiókok és a publikus mappákban található levelek, név- 
jegyek, feljegyzések, találkozók stb. mentése (Brick Level 
Backup). A két mentési eljárás kiegészíti egymást: a teljes leve- 
lezőszervert adatbázismentésből, az egyes postafiókok tartal- 
mát pedig postafiókmentésből lehet helyreállítani. 

Amikor a BrightStor ARCserve Backup hozzáfog az adatbázis, 
vagy annak egy részének mentéséhez, kérést küld a mentőügy- 


working w i 


nöknek. A mentőügynök a kért adatokat az Exchange ég) 
Server Backup/Restore API-csatolón keresztül éri el. ha) 
Az Exchange-kiszolgáló mentése lehet teljes, vagy 

különbségi (inkrementális vagy differenciális). Mind- 

három módon ugyanazt az eredményt kapjuk, az el- 

térés a helyreállítás bonyolultságában van. 










ntáladm - 
zal madbos Store (YANFC2) 
zat pubi Folder Store (VANFC2) 






DE LocalDisk (C:) 
EI Local Disk (D-) 











E Exchange-kiszolgáló mentése 


Ha a mentés sebessége az elsődleges, akkor valamelyik kü- 
lönbségi módszert, ha pedig a helyreállítás sebessége a fonto- 
sabb, a teljes mentést célszerű választani. 

Az adatbázis helyreállítását követően konzisztencia-vizsgálatot 
kell végeznünk. Erre elsősorban az Exchange-kiszolgálóhoz 
adott eseutil . exe szolgál, 


eseutil /mh dbase-file.ext I find /i "consistent" 


de alapszintű vizsgálatra az Exchange-ügynök is képes. 


Az Exchange-ügy- 
nök beállítási le- 
hetőségei 





Az Exchange-kiszolgáló biztonsági mentésének legcélszerűbb 
módja az, amikor a nyugalmi állapotú kiszolgálóról, leállított 
Exchange-szolgáltatások mellett teljes mentést készítünk, majd 
a továbbiakban csak on-line mentéseket végzünk. A nyugalmi 
állapotban készített teljes mentésből gyorsan helyreállítható 
egy működőképes rendszer, ezt követően már csak az aktuális 
adatbázisállapotot kell visszatölteni. Az adatbázis visszaállítá- 
sa során a levelezőszerver felhasználókat nem szolgál ki. 

A postafiókok mentése MAPI-csatolón keresztül történik. Ezt a 
csatolót az Exchange-kliens vagy a Microsoft Outlook tetszőle- 
ges változata tartalmazza. 

Az egyes postafiókok tartalmának helyreállításához az Exchan- 
ge-kiszolgáló normál üzeme szükséges, a felhasználó leve- 
lezőkliensében a visszatöltést követően azonnal megjelennek 
a mentés óta törölt levelek. Természetesen több szűrési felté- 
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Me 


telből is választhatunk a levelek visszatöltése kap- 


. Egylépéses rendszervisszaállítás 
(Disaster Recovery) 


A működőképes rendszer gyors helyreállításának feltétele a le- 
hető legkevesebb kézi beavatkozás a rendszer visszatöltése 
során. 

A hagyományos adatvisszaállítás rendszerépítéssel kezdődik. 
Ennek során: k 

operációs rendszert 

operációs rendszer-javítást 

eszközmeghajtót 

eszközmeghajtó-javítást 

alkalmazásszervert 

alkalmazásszerver-javítást 

telepítünk. 


$888684§ 


Szükséges kellékek: a telepítendő összetevők telepítőkészletei. 
Mindeközben a rendszeren legalább az alábbiakat kell beállí- 
tanunk: 

A partíciós információk 

A hálózati beállítások 

A az alkalmazásszerverek beállításai. 


Szükséges kellékek: a beállítások aktuális változata, nyomtatott 
és/vagy elektronikus formában. 

Ezt követően láthatunk hozzá a felhasználói adatok és az alkal- 
mazásszerverek adatainak helyreállításához. 

A mentőügynökkel készített teljes rendszermentésünk azáltal 
válik alkalmassá az egylépéses rendszervisszaállításra, hogy le- 
gyártunk egy indítókészletet. 

Az indítókészlet tartalmaz egy floppy-lemezt a mentett gép 
egyedi beállításaival, egy módosított operációs-rendszer CD-t, 
és a teljes szalagos mentést. 


(CSOETTIZIT] 





MELocalDsk (CI 
MEDLocal Dek (D.) 


ED recia poci 
B Device 
AZ peport 
8 ven 


0 Backup 





IT bead servert aNTAOZ T 








[3 Adatforrás kijelölése mentéshez 


(1) A mentett gép egyedi beállításait a rendszermentőügy- 
nök gyűjti össze, ha a teljes gépet kijelöljük mentésre. 


A floppy-lemezre a partícionálási adatok és a hálózati beállítá- 
sok kerülnek, valamint ide másolódik a hálózati kártya meg- 
hajtója is. 

Az egyes mentett számítógépek beállításait az ARCserve-ki- 
szolgáló tárolja. A nagyobb biztonság érdekében ezekről az 
adatokról másolat készíthető egy kiválasztott kiszolgálón. 


aAlternate Location for DR Information 





Atthe end of a full backup, the local machines disaster recovery information is 
saved on the BrighiStor ÁRCserve Backup server. 


To save this disaster recovery information to another computer for added disaster protection. 
of the BrightStor ARCserve Backup server, please provide the following information and click 
OK. This wizard only changes the information on the local machine. 


[7 Use altemate path for added disaster protection. 


Altemate Machine Name: KP AE ege Est megnéz EZ ASzEST TETT] 
"windows Domain: Ház Ü 
Password ese SSE 
Path (with the Share Name) ES VSE ESEL ENTEE 


( Example: C$WORalterate or DRalternate if it is a shared folder ) 





SESOKSE Cancel 








E A konfigurációs adatok biztonsági másolata 


A rendszerindító CD-ből mentett operációs rendszer-fajtánként 
egy darabra van szükség, ugyanazzal a CD-vel tudunk egy 
Windows 2000 munkaállomást és egy szervert visszaállítani. 
Ezt a CD-t a BrightStore ARCserve 9 állítja elő ISO-állomány 
alakjában az eredeti operációs rendszer telepítőkészletének 
i386-os könyvtárából és az ARCserve állományokból. 

















2 Winlmage - DÍÁPROGRAM FILESICAYBRIGHISTOR MITET AT Ta 3 lola 
Ele Image Disk Options Help 
D s H]l6 e §] e e? rY [7 72 fa Em] Label: PORT 
Name Sizel Ti Modíified 
CI BOOTDISK Fie Folder 2003/04/04 05:49:18 








CI13es Fe Foldet 2003/04/04 05-49.18 
[dj ARCw2K 0 2003/04/04 05:49.18 
Ed e00T.mG 2048 Wíinimage 2003/04/04 054918 
[d] COROMSPZTST o 2003/04/04 054918 
[aj COROM 14 5 5 2003/04/04. 05:49.18 
[aj COROM NT.5 s 2003/04/04 05.49:18 
[a] COROM SP.TST o 2003/04/04. 05:49.18 
[d] WINNT.SIF 467 2003/04/04. 05:49.18 





( 205444KB. 0 byte free [9 files (2 525 bytes) 





B A rendszerindító CD tartalma 


A gyakorlatban előfordulhat olyan eset, hogy a rendszert háló- 
zaton keresztül mentjük, de a visszaállítás helyi szalagos egy- 
séggel történik. Ilyen esetben a rendszervisszatöltés során a 
számítógép úgy viselkedik, mintha ARCserve-kiszolgáló lenne. 
Természetesen van mód a hálózati adatvisszatöltésre is, ehhez 
a floppy-lemezen található hálózati meghajtót és -beállításokat 
használjuk. 

Ha a szalagos egységünk támogatja a szalagról történő rend- 
szerindítást (One Button Disaster Recovery), kizárólag a teljes 
mentést tartalmazó szalagból is visszaállítható a teljes rend- 
szer. Az OBDR kétségtelen előnye az egyszerűség, ám a szala- 
gos rendszerindítás sajátosságaiból (az állományok nem okvet- 
lenül a rendszerindításhoz szükséges sorrendben helyezked- 
nek el a szalagon) adódóan az első rendszerindulás NAGYON 
lassú, a szalagos egység sebességének függvényében órákig is 
eltarthat. 


Virtuális szalag: merevlemez-alapú mentés 


A szalagos mentési rendszerek szűk keresztmetszete rendsze- 
rint a szalagos egység teljesítménye. A mentési munkákat be 
kell sorolni. A szekvenciális írás hosszú nyugalmi időt igényelt, 
a mentési folyamat hosszasan leterhelte a helyi hálózatot. 

A folyamatos üzemű számítógépes rendszereknél nincsen mód 
a mentendő kiszolgálók tartós leterhelésére mentési célokból; 
a lehető leggyorsabban el kell vinni a mentés adatait, hogy a 
kiszolgáló visszatérhessen az alapfeladatához. 


A BrightStor ARCserve mentési teljesítménye elméletileg 
tetszőlegesen növelhető a mentőkiszolgálóra csatlakoztatott 
szalagos egységek számának növelésével, de a gyakorlatban a 
nagyszámú fizikai mentőeszköz egyetlen kiszolgálóra történő 
csatlakoztatása nehezen valósítható meg. 

A merevlemezek árának rohamos zuhanása oda vezetett, hogy 
a merevlemez-alapú mentés ésszerű választási lehetőséggé 
vált. 

Az ARCserve a lemeztárat virtuális szalagnak tekinti, 


£ BriohtStor ARCserve Backup - [Device:1] A 


EG Ede Manager Wizard View Devke Window Help 


AAG Es a 
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TUICK START EJ 


Job Status 


Devies 















á dlátlült, TS IBM-DARA -212000 
6 a 15 atapi 

a Restore Ő SAMSUNG CD-ROM SN-124 
EB Media Poa 5 In 25 stmozs 

8: Ő Generic STEALTHOVD 

3 In 235 CA FSAdapter 
EB petebsse 2 
ÚJ Report 
Server Admin 
B sen 
FSName8 





ser: caroot [6713 


E Az ARCserve eszközkezelője 


annyi eszközre tud párhuzamosan írni, ahány eszközt létre- 
hoztunk. 








D:lfiesystem-devicetit 
D:filesystem-devicetzt 
D:fiesystem-devicet3t 
D:ifilesystem-devicetőt 
D:lfilesystem-devicetőt 
D:fiesystem-devicetőt 
D:lfilesystem-devicet7t, 
D:jfilesystem-devicetőt, 


To edít a file device, first select the Íne then cick on the altibute you want to change. 





—dtrn [ETT] e] ten] 





B A virtuális szalag létrehozása egyszerű 


Az így létrehozott virtuális szalagos meghajtók megfelelő mé- 
retezés és hálózati kapacitás mellett alkalmasak arra, hogy az 
alkalmazásszerverek adatait nagyon gyorsan befogadják, és 
később ugyanezeket a mentéseket a hagyományos szalagra 
másolják. 

A merevlemez-alapú mentés legfőbb erénye az azonnali adat- 
hozzáférés. Ez az előny azokban az esetekben a legszembe- 
tűnőbb, amikor egy-egy viszonylag kisméretű, de fontos állo- 
mányt kell visszaállítani. Szalagos megoldásnál a hozzáférés 
idejének túlnyomó részét az adott szalag fizikai megkeresése 
és előrecsévélése emészti fel. 


technet Má E d v i 


Vírusvédelem 


A számítógépes rendszerben számos ponton célsze- 
rű ellenőrizni az adatok vírusmentességét, az egyik 
ilyen pont a mentési rendszer. Ha ezen a helyen is el- 
lenőrizzük az adatokat, nem fordulhat elő, hogy a ví- 
rusfertőzést idegen helyről származó szalag okozza, és elkerül- 
hető az egyszer már kiirtott vírus véletlen visszafertőzése egy 
régebbi mentésből történő adatvisszaállítás során. 

A BrightStor ARCserve v9 telepítőkészlete tartalmazza az eT- 
rust InoculatelT 6 engine-t, amely az azonos nevű víruskereső 
lecsupaszított központi eleme. A mentés illetve visszaállítás s0- 
rán a víruskeresés opcionális, feladatonként állítható. 


HENTES ETT 213 


BackupMedia ]  Verification ] Rety  ] Operation ] Pre/Post ] JobLog 
Virus Alet — ]  Replication  ] Media Exporting Advanced 


- 





T 17 Enable Virus Scanning 
Action on infected files: 
C skip 
Do not process this file. 


C Rename 
Rename the infected file with an AVB extension. 


€C Delete 
Delete the infected file. 














A vírusdefiníciós állomány önműködő frissítése az alábbi pa- 
rancssorral történhet, 





akár ARCserve-feladatként, akár külső időzítéssel. 


Jung Tamás 

tamas.jungOca.com 

A szerző rendszermérnök, a Computer Associates 
tanácsadója 

MCSE, CUE, CSS, CNS 
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7-7 ADKEP rejtett szépségei — I. 


Szinte minden TCP/IP hálózat rendelkezik DHCP szolgáltatással. Ez az alkalmazás 


háttérbe húzódik, a felhasználók sohasem találkoznak vele, és ha jól működik, a 
rendszergazdák is csak hébe-hóba vetnek rá pillantást. Itt is érvényes az ókori böl- 
csesség: ami nem látható, az fontosabb, mint ami látható. 


Az Internet elterjedése technikai értelemben a TCP/IP proto- 
kollcsalád széles körű alkalmazását jelenti. Szemben azonban 
más protokollokkal, amelyek nem igényelnek különösebb kon- 
figurálást, a TCP/IP negyedik verziója csak akkor nyeri el ro- 
bosztusságát, ha az üzemeltetők precíz beállításokat végeznek 
rajta. Ha igen sok állomás dolgozik egy hálózatban, a beállítá- 
sok sokszorosan terhelik a rendszergazdát. Kézzel kellene azo- 
kat végezni, méghozzá a helyszínen, hiszen csak a konfigurá- 
ció után lehet hálózati kapcsolatot létrehozni, másrészt a szab- 
vány megköveteli, hogy minden állomás egyedi IP-címmel 
rendelkezzék — ezt csak precíz és naprakész nyilvántartással 
lehet biztosítani. Az adatbázist folyton frissíteni kellene amikor 
egy új gép érkezik, vagy egy eszközt az egyik hálózatból a má- 
sikba kell költöztetni. A problémahalmazra a válasz a DHCP 
szolgáltatás kialakítása. A Dynamic Host Configuration Proto- 
col, vagyis a dinamikus címkonfigurációs eljárás képes auto- 
matikusan az ügyfelek számára egyedi IP-címeket osztani. A 
DHCP egy szabvány (RFC), bármely operációs rendszer hasz- 
nálhatja, ha ismeri. Ma már talán nincs is olyan, amelyiket ne 
készítettek volna fel a címek automatikus kezelésére. Akár egy 
Windows for Workgroups 3.11, egy Linux, vagy egy OS/2 is le- 
het ügyfél. A kliensek viselkedése különböző helyzetekben és 
konfigurációs igényei eltérőek lehetnek, ahogy ezt később 
majd látni fogjuk. 


DHCP alapok 


A DHCP-szabvány megértéséhez néhány TCP/IP alapfogalmat 
precízen ismerni kell. Ezek a következők: IP-cím, alhálózati 
maszk, alapértelmezett átjáró, szórt üzenet (broadcast), útvá- 
lasztó (router). Lakonikus tömörséggel nézzük, mi mit jelent. 
IP-cím: négy számjegyből álló, az adott állomást a hálózaton 
egyértelműen azonosító egyedi cím. A cím két részből áll: a 
hálózati címből és az állomás címéből. Ránézésre nem állapít- 
ható meg, hogy hol ér véget az egyik, és hol kezdődik a másik. 
FI 172:16-314 

Alhálózati maszk: az a szám, amely meghatározza, hogy az IP- 
cím mely része hálózati, és mely része állomáscím. Ennek se- 
gítségével lehet megállapítani egy másik IP-címről, hogy az a 
mi hálózatunkba tartozik-e vagy sem. Pl: 255.255.0.0 
Alapértelmezett átjáró: ha egy olyan címre kell csomagokat 
küldeni, amely nem a mi hálózatunkban van, az állomások az 
alapértelmezett átjáró felé továbbítják az adatokat. A valóság- 
ban az alapértelemzett átjárók többnyire útválasztók (route- 
rek). 

Szórt üzenet (broadcast): egy speciális csomag, amelyet min- 
den állomás megkap, és fel is dolgoz. A szórt üzenetek nem 
jutnak át az útválasztón, mivel általában lokális jelentőségük 
van. Ethernet hálózaton a szórt üzenet MAC célcíme FF-FF-FF- 
FF-FF-FF. 

Útválasztó (router): egy olyan speciális állomás, amely kettő 
vagy ennél több IP-alhálózatot kapcsol össze, és rendelkezik 


VETETT 4: a gi a 


azzal a képességgel, hogy az egyik hálózatból érkezett csoma- 
got a megfelelő útvonalat kiválasztva egy másik hálózatba jut- 
tatja. 
Az alapvető TCP/IP fogalmak mellett meg kell barátkoznunk 
néhány speciális, a DHCP szabványra vagy kiszolgálóra jel- 
lemző definícióval is. 
Scope: Egy folytonos címtartomány 
(Pl.: 10.10.10.1-10.10.10.254), amely- 
ből a DHCP kiszolgáló címeket oszt 


A folyamat megold az ügyfeleknek. (Egy vödör IP-cím — a 
szerk.) Egyszerűbb esetekben a scope 
egy paradoxont: egy alhálózatot reprezentál. 
Superscope: Több scope rendszergaz- 
miként lehetegyál- dák által meghatározott csoportja, 
amely képes több logikai alhálózat 
lomással TCP/IP kezelésére egy fizikai alhálózaton. 
Exclusion range: Azon címek listája, 
szabvány szerint tartománya, amelyeket a DHCP ki- 
szolgáló nem fog kiajánlani az ügyfe- 
kommunikálni úgy, "leknek — például mert már foglaltak. 
Address pool: A címtartomány kioszt- 
hogy az nem rendel- . ható része. 


Lease (bérlet): a DHCP szerver által 
meghatározott időszak, amely idő 
alatt egy ügyfél használhatja a szer- 


kezik IP-címmel, 


ergo képtelen a kom: vertől kapott címet. A bérletet meg 
rög kell újítani, különben lejár és tovább 
munikációra. nem használható. A kiadott bérlet ak- 


tív. Ha nem történik megújítás, a bér- 
let aktív állapotból felhasználható 
(szabad) állapotba kerül, vagyis egy 
másik állomás számára kiadhatóvá válik. 
Reservation (lefoglalás): Állandó cím hozzárendelése egy ügy- 
félhez. Ezzel biztosítani lehet, hogy egy adott eszköznek min- 
dig ugyanaz marad az IP-címe. 
Option types: Az ügyfeleknek átadandó konfigurációs paramé- 
ter. Általában egy scope-hoz adunk meg opciókat, de léteznek 
más lehetőségek is. 
Option classes: Egy másik módszer, hogy az ügyfelek részére 
konfigurációs beállításokat adjunk ki. Az IP-címet igénylő 
rendszerek tisztában vannak a saját gyártójukkal és egyéb tu- 
lajdonságaikkal, ezek alapján speciális konfigurációs beállítá- 
sokat is megértenek. Az adott osztályba tartozó ügyfelek érvé- 
nyesíteni fogják a beállításokat, másokra viszont hatástalan 
lesz. 


A címkiosztás célja és elvei 


A DHCP szolgáltatás legfontosabb feladata, hogy egyedi cí- 
mekkel lássa el azokat az állomásokat, amelyek ezt igénylik. A 
címeket egy előre kijelölt címtartományból, a scope-ból veszi. 
A folyamat szépsége abban rejlik, hogy megold egy parado- 
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xont: miként lehet egy állomással TCP/IP szabvány szerint 
kommunikálni úgy, hogy az nem rendelkezik IP-címmel, ergo 
képtelen a kommunikációra. A megoldás a szórt üzenetek al- 
kalmazása. Ez az egyetlen csomagtípus, amelyet minden állo- 
más feldolgoz, és csak a csomag tartalma alapján dönti el, az 
vajon neki szól-e vagy sem. Lássuk pontosan a folyamatot. 


Az IP-címkiosztás menetrendje 


Egy állomás indulásakor érzékeli, hogy az üzemeltetők statikus 
IP konfiguráció helyett dinamikus cím kérésére állították. A 68- 
as UPD-forrásportról a 67-es UDP-célportra egy ún. DHCP- 
Discover (DHCP-felfedezés) szórt üzenetet indít a hálón. A 
csomag célja, hogy az állomás felhívja magára a figyelmet, és 
arra kérje az ilyen csomagokat figyelő DHCP-kiszolgálókat, 
hogy ajánljanak fel számára címet. 


h4 


DHCP Client DHCP Servers 


IP lease reguest 


IP lease offers 


aes: 

IP lease selection Tr higy sk 
Az ügyfél és a 
DHCP szerver kez- 


IP lease acknowledgment 





deti csomagváltásai 


A szerver vagy szerverek az üzenetet feldolgozzák, és szintén 
broadcast módszerrel elküldik felajánlásukat (feltéve, ha van 
kiosztható címük). Ezt a csomagot nevezzük DHCP-Offernek 
(DHCP ajánlat). 

A beérkezett ajánlatból vagy ajánlatokból az állomás kiválaszt- 
ja a neki megfelelőt, és még mindig a szórt üzenettípust hasz- 
nálva egy DHCP-Reguest (DHCP kérés) csomagot küld el a há- 
lózaton. A csomagban elhelyezi annak a szervernek az azono- 
sítóját, amelytől a címet kéri. A szórt üzenet azért hasznos, 
mert bár az állomás már tudja a kiválasztott szerver címét, a 
broadcast csomaggal könnyen értesítheti a többi szervert a vá- 
lasztásáról, így azok erre a szórt üzenetre úgy reagálnak, hogy 
korábbi ajánlatukat visszavonják. A visszavonás nem jár háló- 
zati forgalommal, csupán a felajánlott cím kerül újra felajánl- 
ható státuszba. 

Ha a DHCP-szerver elfogadja a kérést, egy DHCP-Acknowled- 
gement (DHCP-jóváhagyás) csomaggal nyugtázza az ügyfél fe- 
lé, továbbra is szórt üzenettel. Ekkor kapja meg az ügyfél az 
egyéb DHCP-opciókat is. A kiszolgáló rögzíti kliense legfonto- 
sabb adatait az adatbázisban, többek között a host nevét, 
MAC-címét, és a bérlet lejáratának időpontját. 

Igen ritka esetben az is előfordulhat, hogy nem fogadja el a 
szerver a kérést, ekkor egy negative acknowledgement (DHCP- 
Nack) csomagot kap az IP-címet kérő gép, amely azután újra- 
kezdi az eljárást. 

Látnunk kell, hogy nem igazán vagy nem csupán egy IP-címet 
kap a számítógépünk, inkább egy engedélyt arra vonatkozóan, 
hogy egy meghatározott ideig használhat egy adott IP-címet — 
néhány további paraméterrel együtt. Ebből következik, hogy 
nem a fenti az egyetlen kommunikáció a DHCP-szerver és az 
ügyfél között. 


Kommunikáció a DHCP-szerverrel 42) 


Az IP-cím boldog tulajdonosa legközelebb egy új- 4) 
raindításkor fog kapcsolatba lépni a címkiosztó szol- 
gáltatással. Azt várnánk, hogy a fentiekkel teljesen 
megegyező párbeszéd zajlik majd le, de tévedünk. 

Az ügyfelek ugyanis eltárolják a bérletre vonatkozó összes in- 
formációt, vagyis tisztában vannak azzal, hogy őket megilleti 
egy cím. Ezért induláskor DHCP-Discover helyett egy DHCP- 
Reguest csomagot küldenek, amelyben a korábban már elnyert 
IP-címet kérik célzott üzenet formájában, megspórolva két cso- 
magot, némi időt és sávszélességet. A kiszolgáló ezt rendesen 
DHCP-ACK üzenettel nyugtázza, és az élet megy tovább. 

Ha azonban a ki- és bekapcsolás között fontos változások tör- 
téntek, például a hordozható gépünket egy másik telephelyen 
kapcsoltuk be, más eredménye lesz a csomagváltásnak. Az új 
alhálózatban a másik DHCP-szerver megkapja a DHCP-Regu- 
est csomagot, mert a szórt üzenetet fel kell dolgoznia. Mivel a 
kért cím nem az ő hálózatából való, DHCP-Nack csomaggal 
válaszol a kérésre. Az ügyfél ezután , elfelejti" a korábbi címét, 
és egy szabályos IP-cím igénylésbe kezd. No, és mi van, ha a 
notebook-ot az otthoni hálózatba kapcsoltam be, ahol nincs is 
DHCP szerver? 

A szituációban a különböző operációs rendszerek eltérő mó- 
don viselkednek. Ha a rendszer Windows 95, vagy Windows 
NT 4.0, esetleg ezeknél korábbi változat, az ügyfélszoftver azt 
feltételezi, hogy nem változott a helyzete, csak a DHCP-szer- 
ver nem érhető el! A válasz nélkül maradt DHCP-Reguest cso- 
mag arra készteti az ügyfelet, hogy ellenőrizze, érvényes-e 
még a bérlete. Amennyiben a válasz igen, a rendszer a koráb- 
ban megkapott IP beállításokkal elindul. Ha a bérlet már nem 
érvényes, a hálózati protokollt nem tölti be a szoftver. 
Windows 98-tól felfelé, valamint Windows 2000-nél és Win- 
dows XP-nél már okosabbak az eszközök. Ha nem jön válasz 
a DHCP-Reguest csomagra, az operációs rendszer kísérletet 
tesz arra, hogy eldöntse, vajon a ,helyén" van-e még és csak a 
DHCP-kiszolgáló nem érhető el, vagy egy új hálózatban mű- 
ködik, ahol nincs DHCP-szolgáltatás. A trükk egyszerű, egy 
ICMP (ping) csomagot küld az alapértelmezett átjáró felé. Ha 
választ kap, a rendszer ott ébredt fel, ahol kikapcsolták, és a 
DHCP-szolgáltatással van probléma. Ellenkező esetben, tehát 
ha az átjáró sem válaszol, a feltételezés az, hogy nem a saját 
helyén indították a rendszert — ekkor használja a szoftver az 
APIPA képességét. Tegyünk egy kis kitérőt, és nézzük meg, mi- 
ről van szó. 


Csináld magad DHCP: az APIPA 


A rövidítés az Automatic Private Internet Protocol Addressing 
kifejezés rövidítése, magyarul automatikus magán IP-cím 
kiosztási eljárás. A Microsoft otthoni és kisebb irodai hálóza- 
tokhoz vezette be a még csak draft formájában létező APIPA-t, 
olyan helyekre, ahol bizonyosan nincs kiszolgáló, mert nem 
érné meg, és nincs szaktudás sem a hálózat konfigurálására. 
Az APIPA működése egyszerű: ha induláskor az operációs 
rendszer nem talál DHCP kiszolgálót, a draft által lefoglalt, B- 
típusú IP-címtartományból (7169.254.0.0, subnet mask: 
255.255.0.0) véletlenszerűen kiválaszt egy címet, meggyőző- 
dik arról, hogy azt más nem használja, majd elindul. A meg- 
győződés annyit tesz, hogy egy ICMP csomagot indít a kivá- 
lasztott cím felé. Ha érkezik rá válasz, már létezik a cím a há- 
lózatban, tehát másikat kell keresni. Tízszer próbál így címhez 
jutni, és tekintve, hogy 65535 a lehetséges címek száma, kicsi 
az esélye, hogy nem találja meg az , igazit". 
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Az automatikusan meghatározott címhez azután 
nem ragaszkodik, és minden ötödik percben kibocsát 
egy DHCP-Discover csomagot, hátha meggondolták 
magukat az üzemeltetők és működőképes állapotba 
hoztak egy címkiosztó szolgáltatást. 

A DHCP és az APIPA azért fér meg egymás mellett, mert az 
operációs rendszer el tudja dönteni, hogy milyen szituációban 
van. Ha korábban már kapott IP-címet, most pedig nem, 
ugyanakkor az alapértelmezett átjáró működik, vélhetően a 
DHCP-szerver áll. Sebaj, a korábban kapott, és érvényes bérle- 
tet lehet használni. Ha az alapértelmezett átjáró sem működik, 
úgy nincs is DHCP a közelben. Sebaj, ad magának címet az 
APIPA eljárással. Így vagy úgy, de az ügyfél IP-címhez jut. Per- 
sze, ha olyan régóta nincs már DHCP-szolgáltatás, hogy a bér- 
let lejárt, a rendszergazdák szándéka ellenére az APIPA segít- 
ségével éled fel a hálózat, de ez már nem az operációs rend- 
szer felelőssége. 


9 


További DHCP-üzenetváltások 


A bérlet egy meghatározott időtartamra vonatkozik, a bérlet le- 
járati dátummai rendelkezik. Az időtartamba beletartozik a ki- 
kapcsolt állapotban eltöltött idő is. Ha eltelik a bérleti idő fele, 
az ügyfél egy megújítási kérelmet küld annak a DHCP-kiszol- 
gálónak, amelytől a címet kapta. Nincs szükség szórt csoma- 
gokra, az üzenetváltás közvetlen. Ha nincs válasz, 4, 8, majd 
16 másodperccel később újra próbálkozik az ügyfél. A szerver 
egy DHCP-Ack csomaggal jelzi, hogy elfogadja a bérlet meg- 
hosszabbítását. 

Amennyiben egy szerencsétlen véletlen miatt nem sikerül 
megújítani a bérletet félidőben, nem történik semmi, az ügyfél 
továbbra is kommunikációképes. Amikor a bérlet időtartamá- 
nak 87,599-a is eltelt, az igénylő újra próbálkozik. Ha ezúttal 
sem jár szerencsével, már felébred benne a gyanú, hogy vala- 
mi gond van a kiszolgálóval, ezért a unicast, vagyis direkt cso- 
mag helyett ismét előveszi a régi trükköt, szórt üzenetet küld a 
hálózatra, hátha van ott DHCP-szolgáltatás, csak egy másik 
szerveren. Más kiszolgálók persze DHCP-Nack csomagot kül- 
denek, de sebaj, ekkor újraindul a címigénylési eljárás, a vég- 
eredmény pedig egy új bérlet kiadása. 

Ha minden jóakaratunk ellenére 87,599-nál sem sikerül a bér- 
let megújítása (még az újra bevetett 4, 8, és 16 másodperces 
újrapróbálkozás ellenére sem) a következő kérelem a bérlet le- 
járatakor esedékes. A sikertelenségnek már kommunikációs 
következményei vannak. Ha a rendszer ismeri az APIPA mód- 
szert, azzal szerez címet, de ha nem ismeri (Win95, NT4), cím 
(és hálózat) nélkül marad. 


Néhány szó elöljáróban a DHCP megbízhatóságáról 
Miután áttekintettük a lehetséges üzenetváltásokat, vizsgáljuk 
meg, hogy egyetlen kiszolgálóval, és némi ügyes beállítással 
milyen rendelkezésre állást tudunk biztosítani. A DHCP egy 
alapvető szolgáltatás, a legfontosabb kérdés mindenek előtt te- 
hát az, vajon mennyire bízhatunk benne. 


Láttuk, bármely ügyfél, amely képes eltárolni a saját bérletére 
vonatkozó információkat, a DHCP-kiszolgáló nélkül is képes 
használni a bérletét, sőt az sem probléma egy darabig, ha a 
megújítás nem sikerül. Egy egyszerű újraindítást a felhasználók 
nem vesznek észre. Az is bizonyos, hogy a kiszolgáló kiesését 
nem ugyanakkor észlelik majd a kliensek, hanem a bérletük le- 
járatakor. Az alábbi ábra mutatja, hogy egy átlagos ügyfél vél- 
hetően a bérletidő negyedénél jár (de nem zárható ki, hogy 
van olyan delikvens, amely már kitöltötte a saját idejét, pl. na- 
pokig nem volt bekapcsolva). 


Az ügyfelek száma 


5090 10096 


Az eltelt bérleti idő 


E Az ügyfélszámítógépek eloszlása az eltelt bérletidő 
függvényében 


Mennyi ideig állhat egy DHCP-szolgáltatás? A hiba nem azon- 
nal jelentkezik, hanem apránként. Előbb egy gép esik ki, majd 
még egy, majd egyre több. Ha a bérletidő felénél tovább áll a 
szerver, az ügyfelek többségét érinteni fogja. Ebből viszont az 
következik, hogy a bérletidő növelése a hiba eszkalálódásának 
sebességét csökkenti. Ha tehát csupán egyetlen szerverünk 
van, és vélhetően csak lassan tudjuk megjavítani a DHCP-ki- 
szolgálót, nyugodtan növeljük meg a bérleti idő hosszát (per- 
sze még a hiba előtt), így vélhetően nagyon kevés gép esik ki, 
amíg a problémát elhárítjuk. Szegény ember statisztikai alapon 
biztosíthat magasabb rendelkezésre állást. 

No persze gép és gép között jelentős különbség lehet. Ha ne 
adj" Isten épp a főnökünk gépe, vagy az ő főnökének a PC-je 
nem működik, nincs mérlegelési lehetőségünk, gyorsan kell 
cselekednünk és javítanunk. A jövőbeli fejmosások elkerülése 
érdekében pedig előbb-utóbb gondoskodni kell valahogyan a 
kiszolgáló többszörözéséről. Sokféle lehetőségünk van, ké- 
nyelmesek és drágák, olcsóbbak és több beavatkozást igény- 
lők. A kiszolgáló funkcióinak ismertetése után visszatérünk 
még a rendelkezésre állás kérdésére, már csak azért is, mert 
összetett DHCP beállításoknál nem is mindig könnyű megol- 
dani a problémát. 


Lepenye Tamás, MCSE 2000 
lepenyetemal.hu 


Parancssori környezet És 


pszközük 


Halál a GUl-ra 


Sok UNIX-os szakember nézte le a Windows kiszolgálókat, mert csak grafikus környezetből lehetett 
üzemeltetni őket. Megpróbálom bebizonyítani, hogy az új generációs Windows kiszolgálókat immá- 
ron kizárólag parancssorból, manuálisan (és automatizáltan is) lehet mindenre kiterjedően adminiszt- 
rálni, konfigurálni és felügyelni. A cikkben — ismétlésképpen — némi DOS-ismeretet is megemlítek azon 


fiatalok kedvéért, akik akkor még nem éltek... 


A Windows Server 2003 családban történt fejlesztésekkel a 
Microsoft nagy lépést tett előre a kiszolgálók kezelésével, felü- 
gyeletével és konfigurálásával kapcsolatban. Sok rendszergaz- 
dának és mérnöknek jelent könnyebbséget ezen eszközök ma- 
nuális vagy batch, esetleg scriptalapú automatikus használata. 
Közepes és nagy hálózatokban, heterogén környezetben a 
Windows 2000 még hagy(ott) némi kivánnivalót maga után, 
ugyanis még a resource kit eszközeivel sem volt megoldható 
minden erről a felületről. Azért egyáltalán nem mindegy, hogy 
egy eszközt konyhakészen kapunk, vagy nekünk kell összeva- 
rázsolni, barkácsolni valamit! 

Mivel még kiadás előtt álló, nem végleges szoftverről van szó, 
pontosítanám hogy a Release Candidate 2 verzió publikus 
(CPP, build 3718) változatából kiindulva dolgoztam. 


Az újdonság erejével 

A Windows XP-vel kezdődött minden. Külön csoport jött létre 
a fejlesztők között, hogy megfelelő előkészítő felmérések után 
offenzívát indíthassanak a parancssori eszközök komoly 
bővítéséért. A felismeréshez hozzátartozik, hogy a teljes birtok- 
lási költség (TBK — TCO) jelentősen csökkenthető a rutin felü- 
gyeleti feladatok megfelelő automatizálással, amely nagy mér- 
tékben befolyásolhatja a nagyvállalati IT vezetők beszerzési 
döntéseit. 

Mindegyik parancsnak ismernie kell a /? kapcsolót, amelyre a 
szintakszisát és a súgóját kell válaszként visszaadnia. Telneten 
és terminál-szolgáltatási felületeken keresztül is teljes funkcio- 
nalitásukat kell megbízhatóan nyújtani. És talán a legfonto- 
sabb, hogy a hagyományos parancssori konvencióknak megfe- 
lelően az Stdin, Stdout és Stderr portokkal kell működniük. A 
távoli futtatás egységesítése a /5S kapcsolóval megoldott, vala- 
mint a telneten és a terminál-szolgáltatáson keresztüli műkö- 
dés is garantált. 

Az XP-s fejlesztések, egységesítések, és eszközök igen nagy ré- 
szét egy az egyben átvették a Windows Server 2003-ba is. 


Support tools 


Mivel szükségünk lehet az alapterméken kívüli — Support Tools 
— eszközökre is, a telepítésükhöz indítsuk el a Server CD-ről az 
alábbi állományt a Windows Explorerben: 


cx : KMSupportNToolstsSuptoo]s. msi 


A telepítési varázsló használata egyértelmű, ezért nem részle- 
tezném külön. A teljes telepítést stílszerűen tisztán parancssor- 
ból is megtehetjük, íme: 


msiexec /i x:lsupportitoolsísuptools.msi 
$/a ADDLOCAL-ALL 


Ezen csomag tartalmát eredetileg Microsoft támogatási mérnö- 
kök -— azon belül is specialisták — munkájának elősegítésére ké- 
szítették, ezért ne lepődjünk meg ha nem svájci bicskaként 
funkcionálnak. Céleszközök. Azonban jónéhány, hétköznapi 
hibakeresésben is hasznos diagnosztikai eszköz található meg 

benne: a netdiag.exe és a dcdiag.exe. 

Ezen felül sok grafikus felületű segéd- 

program is található a csomagban, 
Eeidáig az egér nélkül amelyekre nem fogok kitérni. Van rá 
példa, hogy egy segédprogram pa- 
rancssori változata mellé külön grafi- 
kus felületű verziót is adnak. Például 
volt a szakmai MÉICE, az installációs készleteket pucoló esz- 
közök esetében is így van — az 
MsiZap.exe-re épül az MsiCuu.exe 
grafikus programocska. 


kezelt [indowws 


mostantól tisztán 


parancssori rendszer 
Segítség! Help! 
üzemeltetés 1252 a2... A súgó. A színpadon oly fontos erőfor- 
rást hálistennek itt már nagyon komo- 
lyan készítették el, a korábbiakban 
mostohaként és számkivetettként kezelt parancssori eszközök 
dokumentációja immáron bőven eléri a kívánatos szintet. Az 
alaptermékben található parancssori eszközök a ntcemds.chm, 
a Support Toolsban találhatóak pedig a suptools.chm behívásá- 
val ismerhetők meg. A .chm típusú súgóállományokat vagy 
Windows Intézőből duplaklikkel, vagy a parancssorból a 


hh.exe helpfilename.chm ki E 


futtatásával indíthatjuk el — a .exe kiterjesztés persze elhagyha- 
tó. Ilyen korrekt, részletes súgóállományt már régen láttam, 
főleg a Support Tools esetében. Egy egyszerű ,whoami" pa- 
rancs a /? paraméteres futtatásával 57 soros választ adott vissza 
(üres sorok nélkül). Egyes eszközökről bővebben olvashatunk a 
Support Knowledge Base-ben is. 

Ha kollegiális segítséget keresünk ezen eszközökkel kapcsolat- 
ban, sajnos még nem érhetőek el a Windows Server 2003-as 
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E dedikált hírcsoportok. Azonban a Tech.NET levlis- 
a tákon kívül a news.microsoft.com NNTP news szer- 


verén keresztül a [emdadminl] című hírcsoportban ta- 

lálhatók a Windows 2000-re vonatkozó információk. 

Remélhetőleg a végleges termék megjelenésével egy 
időben elindul a Windows Server 2003-as megfelelője is. 


Batch, script — automatizáció 


Ez a téma kevésbé kötődik az új Windows Server verziókhoz, 
azonban az új eszközök leghatékonyabb felhasználási területe 
talán az automatizáció, és ezen területet immáron a Microsoft 
is kellő súllyal kezeli. Felhasználási körük szinte végtelen, 
leginkább a login scriptek, a tömeges címtári felhasználó vagy 
egyéb objektum-módosítások, illetve időzített feladatok korrekt 
kivitelezésénél jönnek jól. Számomra a komplex környezetek 
testreszabott, offline mentéseinél nyújt nagy segítséget a 
batchek használata. 

Sok helyen összemosódik ez a két kvázi-programozási fogalom 
(még hivatalos MS dokumentációban is — lásd login script, ami 
ebből a szempontból félrevezető). Én az alábbiakban definiál- 
nám őket, mivel a komolyabb scriptelés ezen cikk határain kí- 
vül esik. A batch programozás az alap parancssori környezet 
beépített képességeire építve képes futtatni, valamint egymás- 
ba fűzni és átírányítani egyes programok futását, kimenetét. Pa- 
raméteres futtatással behelyettesítődnek a megadott értékek. A 
batch programozásnak DOS-os időkből nagy hagyományai 
vannak, alapjaiban nem változott meg semmi, de sokkal egy- 
szerűbben tudjuk használni a Windows Server parancssori esz- 
közöket ilyen módon. 

Komplexebb, és inkább programozói vénát igénylő feladat 
scripteket készíteni. A Cscript és Wscript beépített interpreterek 
segítségével futtatható programok egy adott scriptnyelven 
(VBScript vagy JScript) írnatók, amelyekben változók és egyéb 
programozási erőforrások is rendelkezésre állnak. 

Egy adott automatizációs feladat általában elvégezhető mind- 
két típusú megközelítéssel, a batch használata azonban gyor- 
sabb tud lenni kevésbé összetett feladatoknál. A scripteléssel 
kapcsolatos fenntartásaikat pedig érdemes levetniük a tartóz- 
kodóknak, ugyanis millió sornyi minta-kód adatbázis érhető el 
a Microsoft Technet és MSDN weboldalán a [scriptcenter] és 
(Iscr samples] címeken. 


Az Stdin, StdOut, StdErr portok egységes használata teszi le- 
hetővé, hogy a batchfolyamatokba programok kimenetét 
átfűzzűk, esetleg átkössük egy másik parancs bemenetére 
(pipe). Az Stderr hibakezelés kapcsán megemlítendő, hogy 
megszokás szerint a 0-át visszaadó program hibátlanul futott 
le, míg integer számot visszadva azonosítható a futtatási hiba. 
Ezen hibakódok megismeréséhez az alapdokumentáció kevés, 
néhány eszköz esetében a /? paraméter kilistázza, de a Micro- 
soft a még el nem érhető Resource Kit-re hivatkozik ezügyben 
(reskit2003]. 

Érdekes lehetőségeket biztosítanak több parancs összekötött 
végrehajtására a feltételes feldolgozási jelek. Két parancs kö- 
zül, amelyek ilyen jellel lettek összefűzve, mindig a bal oldali 
futási eredménye alapján indul el a jobb oldali: 


TA 8 egyszerű, feltétel nélküli összefűzés; 

FA 88 a második parancs csak az első sikere esetén fut le 
(if errorcode — 0); 

A II az előző fordítottja, azaz csak sikertelenség esetén 
indul a második (if errocode 5 0). 


Megjegyzendő, hogy hagyományos zárójelekkel tovább cso- 
portosíthatóak a parancsok, valamint hogy ezen speciális jele- 
ket idézőjelben kell használni, ha argumentumként akarjuk to- 
vábbadni őket. 


Az alábbi parancsokat kifejezetten batch programozáshoz 
használhatjuk: 

AA Call: másik, külső batch meghívása, párhuzamos futta- 
tással 
Choice: felhasználói bevitel bekérése, pl. IGEN/NEM 
Echo: a kimeneti kiíratás szabályozása 
Endlocal: környezeti beállítások lezárása, a setlocal 
után 
For: ciklikus futtatási függvény 
Goto: a jó öreg programozási ellenség itt megváltó is 
tud lenni — ugrás megadott sorra, címkére 
If: feltételes végrehajtás 
Pause: futtatás felfüggesztése, felhasználói beavatko- 
zással továbblép 
Rem: megjegyzések beszúrása a , forráskódba" 
Setlocal: helyi környezeti beállítások 
Shift: futtatási paraméterek átadása 


B88B BB 88 $88B 


Ezekről bővebbet az eljövendő cikkekben próbálok átadni. 


Az átirányítással lehet olyan feladatokat megoldani, ahol az 
egyes programok között együttműködés, paraméter-átadás 
vagy naplózás szükséges. Az itt bevezetendő ,handle" kifeje- 
zést talán kezelési felületként lehetne fordítani. Ez lenne az 
összefoglaló neve a Stdin, StdOut, StdErr, valamint további ki 
és bemeneti adatfolyamoknak, amelyeket 0-tól 9-ig számoz- 
nak. Egy átirányítás ugyanis nemcsak fájlba történhet, 


dir 5: dir.txt 


hanem bármely kezelési felületről megtehetjük ezt bármely 
másikra. Az alábbi operátorokkal dolgozhatunk: 

H : Parancs kimenetének átirányítása fájlba vagy eszköz- 
re (pl. nyomtatóra), a parancssori ablak vagy kezelési 
felület helyett. 

2 Parancs bementének beolvasása fájlból, parancssori 
bevitel vagy kezelési felület helyett. 

55 Kimenet átirányítása fájlba, nem felülírva, hanem 
kiegészítve annak tartalmát. 

58 Adott kimeneti kezelési felület átirányítása másik 
bemeneti kezelési felületre. 

cg Adott bemeneti kezelési felület átirányítása másik 
kimeneti kezelési felületre. 
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Utóbbi két esetben pontosan azonosítanunk kell a kezelési 
felületet. Ezek a következő azonosítók: Stdin 0, StdOut 1, 
StdErr 2, majd 9-ig az adott program által egyedileg definiáltak. 
Ha egy írásvédett fájl törlésének futtatási eredményét simán (-) 
átirányítjuk egy fájlba, csak a fájl nevét kapjuk meg. Azonban 
ha a hibakezelési kimenetet (StdErr, vagy 2) is bevesszük a kép- 
be az alábbiak szerint, a megadott fájlban a hibaüzenet lesz! 


del irasvedett.exe : kimenet.log 2-£1 


Speciális alváltozata az átirányításnak a ,csövezés" (pipe), 
ahol az először lefutó program teljes kimenetét (StdOut) bead- 
juk a következő program bemenetére (StdIn). Jól ismert példá- 
jaa 


parancs.exe ] more 


ahol is a , more.com" program formázása oldalakra tördelve je- 
leníti meg az adott parancs kimenetét. 

A két típusú átirányítást kombinálva hasznos szűréseket végez- 
hetünk: 


dir /b I] find "LOG" 5 loglist.txt 


Ez esetben a dir listázás eredményei közül a find.exe segítsé- 
gével kiszűrt ,log" szót tartalmazó állományok/könyvtárak lis- 
táját a loglist.txt-ben kapjuk meg. 

Szűréshez kapcsolódik még a clip nevű újdonság, amely a find 
és more parancsokon kívül a I csövezést igényli. Segítségével 
a Clipboardra (vágólap) irányítható egy parancssori futtatás ki- 
menete. 


GES KEGTi 
A readme.ttt tartalma ezzel másolható be a Vágólapra. 


clip c readme.txt 


Parancssori futtatási környezet 


A Cmd.exe, mint témánk központi személyisége biztosítja szá- 
munkra a parancssori munkakörnyezetet. A jó öreg 
Command.com leváltója komoly odafigyelést érdemel, 
testreszabása több szinten is megoldható és hasznos. A rend- 
szerszintű beállítások mindenre kiterjednek, míg a helyi beál- 
lítások csak egy adott bejelentkezett felhasználó vagy egy 
konkrét cmd.exe példány futásakor érvényesek. További le- 
hetőségeket biztosít batch környezetben a ,nesting" technika, 
amely a cmd.exe többszöri, egymásból kiinduló futtatását je- 
lenti. Az egyes cmd.exe futó példányra vonatkozó beállítások- 
hoz használhatóak a setlocal/endlocal kapcsolók. 

A környezeti változók közül talán a legismertebb 90PATH?99, de 
sok más, gépre és felhasználóra vonatkozó opció is létezik. A 
teljes lista az említett ntemds.chm helpben található meg. 
Beállításuk a set parancssal történik, behelyettesítésük pedig 
parancssori és batch környezetben akkor történik meg, ha 
9ováltozó9o formában adjuk meg. Login scriptekben igen hasz- 
nosak a 99USERNAME9 és a Y0USERPROFILE99 változók. 


A parancssor testreszabásához kevésbé mission-critical, de ké- 
nyelmes és hasznos lehet a könyvtár- és fájlnév-kiegészítés be- 
kapcsolása. Ekkor kényelmesen, mondjuk a TAB billentyűvel 
tudunk válogatni az adott könyvtárban található bejegyzések 
között. A regisztrációs adatbázist kell módosítani az alábbiak 
szerint: 


HKEY LOCAL MACHINENYSoftwarelMicrosoftiCommand 
ProcessorlCompletionChar 


RegDWORD típusú értéket kell adni, a TAB esetében 9-et. Úgy 
tűnik, hogy gyárilag bekapcsolva kapjuk már ezt az opciót. 
Magának az ikonról indítható Cmd.exe-nek a megjelenését a 
bal felső sarokban található c:X ikonocskán keresztül elérhető 
Properties menüben szabályozhatjuk. A Layout fülön a Buffer 
Size Height megnövelésével a képernyőről már kifutott dol- 
gokra is visszalapozhatunk. A Windows Size Height paramé- 
terével pedig 25-ről mondjuk 50 sorosra növelhetjük az alap 
cmd.exe-t. Ha ezután az OK-t választjuk, a rendszer illedel- 
mesen megkérdezi, hogy csak az e pillanatban futó parancs- 
sort változtassa meg, vagy magát az ikont, amivel mindig in- 
dítjuk a cmd.exe-t. A ,Modify shortcut that started this 
window" ez utóbbit végzi el. A Colors fül babrálásával pedig 
akár az alábbi eredményt is elérhetjük: 





E The Matrix has you (fekete alapon zöld) 


Hatásvadászok (lásd Mátrix) és nosztalgiázók (lásd nagygépes 
terminál) a parancssori környezetben a karakterek színét két 
mozdulattal zöldre állíthatják. 

Amennyiben a Start menü Run segédletével indítottuk el a 
cmd.exe-t, az ilyen jellegű testreszabások után az OK az aláb- 
bi lehetőséget adja fel a ,modify shortcut" opció helyett: 
,Save properties for future windows with same title". Ezzel 
örökíthetjük a beállításokat minden Run menüpontból indított 
cmd.exe-re. 


Új eszközök a szerszámosládában 


Nos, az említett ntemds.chm help dokumentumból kiindulva 
megkülönböztethetjük a teljesen új eszközöket (a Windows 
2000 Server alaptermékhez képest) a megváltoztatott, de már 
korábban is létező parancsoktól. Ezen felül egy homályos ka- 
tegória, a származási törzskönyv is létezik, amit mindenkinek 
a történelem-ismeretére bízok: azaz honnan származik egy 
adott eszköz? Egyes elemek ugyanis korábbi Server változatok 
Support Tools vagy Resource Kit csomagjaiból erednek, sokan 
pedig a Windows XP-ben láttak napvilágot jelenlegi formájuk- 
ban. Sok sikert a nyomozásban! 

A régebbi, most megújult eszközök közül kiemelném a 
diskperf, az rmdir valamint az xcopy parancsokat. A diskperf 
ezennel hatályát vesztette, ugyanis mind a logikai mind a fizi- 
kai diszk teljesitmény számlálók automatikusan engedé- 
lyeződnek ha bekapcsoljuk őket. Kompatibilitási okokból ma- 
radt meg, az IOCTL DISK PERFORMANCE paramétert erősza- 
kosan követelő applikációk számára. Az rmdir mostantól ren- 
delkezik egy /s kapcsolóval, amivel nem üres könyvtárakat is 
hajlandó legyalulni. Az xcopy /g használatával a titkosított ál- 
lományok másolása esetén a célkönyvtárba megérkező máso- 
lat már nem lesz titkosított (ha megvan ehhez a megfelelő pri- 
vát kulcsunk). 

Az MSDOS óta megszüntetett parancsokról is található a 
helpben egy szép lista, nekrológgal együtt. Itt tudhatjuk meg 
hogy az fdisk helyett már a diskpart használandó partício- 
nálásra. 

Az új parancssori eszközök listája nem rövid. A Support Tools 
nélkül 63 bejegyzés található a helpben a , New commandline 
tools" címke alatt, azonban jónéhány új tétel kimaradt ebből a 
kigyűjtésből. A , Commandt-line reference A-Z" címke ABC sor- 
rendben közli az összes parancsot, és részletes leírásukat. 
Funkcionalitás alapján csoportosítva sajnos csak a Support 
Tools eszközei vannak. Egyszer talán még megérjük, hogy a 
Microsoft a rendelkezésünkre bocsásson egy csoportosított, 
teljes indexet az alaptermék, a Support Tools és a Resource Kit 
parancssori eszközeiről. 

Ha saját csoportosításomra építek, az alábbiakat lehet nagyjá- 
ból megkülönböztetni (a teljesség igénye nélkül): 
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" Halál a GÜ[-ra / 


Parancssori környezet és eszközök 
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Active Directory 

dsadd: objektum hozzáadása 

dsget: objektum attribútumának lekérdezése 

dsmod: objektum módosítása 

dsmove: objektum mozgatása 

dsguery: objektumok lekérdezése kritériumok alapján 
dsrm: objektum törlése 

adprep: migráció előkészítéséhez (sémamódosítást vé- 
gez) 
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Internet Information Services 

TA iisapp: adott applikációs pool kiszolgálását végző szá- 
lak azonosítására 
iisback: metabase és séma adatbázisok mentéseit keze- 
li, helyben és távolról 
iiscnfg: az IIS konfigurációjának teljes vagy részleges 
importálására és exportálására 
iisext: kiterjesztések, alkalmazások vagy egyedi fájlok 
kezelésére 
iisftp: ftp helyek kialakítására, vezérlésére 
iisftpdr: ftp virtuális könyvtárak kezelésére 
iisvdir: www virtuális könyvtárak kezelésére 
iisweb: webhelyek kialakítására, vezérlésére 
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Printers 
prncníg: printer konfiguráláshoz, paramétereinek meg- 
jelenítéséhez 


B 


A prndrvr: driverek telepítése, eltávolítása helyi vagy tá- 
voli printszerverekről 

HA prnjobs: nyomtatási munkák (job-ok) teljeskörű kezelé- 
sére 

HI prnmngr: nyomtató-kapcsolatok létrehozáshoz, vezér- 
léséhez 

HA prnport: TCP/IP nyomtatóportok kezelésére 

A prngctl: tesztoldal nyomtatása, várakozási sor felügye- 


lete 


Disk 

A diskpart: diszk, partíció és kötet teljeskörű kezelése 
(hibatűrő és egyéb bonyolultabb konfigurációkat is 
kezel) 
defrag: töredezettség-menetesítés 
fsutil: kötetkezelés, felcsatolás, lebontás 
freedisk: szabad tárkapacitás vizsgálata 
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Network 
HA getmac: hálózati adapterek MAC azonosítójának lekér- 
dezése 
A waitfor: több gépen futó végrehajtások szinkronizálása 
A openfiles: nyitott fájlok kezelése, lezárása 


Cluster/NIb 
HA nib: a WIlbs.exe utódja, hálózati terhelésmegosztás ve- 
zérlésére 
A nibmgr: NLB fürt konfigurálása, vezérlése 


Performance, eventlog 

logman: teljesítmény-figyelés vezérlése 

perímon: NT4 kompatibilis teljesítmény-figyelés 

relog: teljesítmény-naplók konverziója, adatkinyerés 
typeperf: teljesítmény-figyelés kiíratása emgadott helyre 
eventcreate: eseménynaplóba beíratás 

eventguery: eseménynapló lekérdezése 

eventtriggers: eseményi-kezdeményezések kezelése 
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Group policy 
AA gpresult: kiírja a GP beállításokat és Resultant Set of 
Policy kiértékelést végez 
TA gpupdate: a secedit /refreshpolicy utódja, az XP-ben 
már ismerkedhettünk vele 
HA dcgpofix: GP alapértelmezésre állítása, "full GP reset" 


General 

cmdkey: felhasználói azonosítók letárolása, kezelése 
driverguery: driver-szoftverek listázása, tulajdonságok 
forfiles: parancsok automatikus futtatása nagy mennyi- 
ségű fájlon 

helpctr: Help and Support Center indítása 
pagefileconfig: a lapozóállomány teljeskörű vezérlése 
sc: szolgáltatások vezérlése 

shutdown: gépek leállítása, újraindítása helyben és tá- 
volról 

takeown: NTFS tulajdonjog átvétele 

taskkill: feladatok kilövése, a korábbi kill.exe utódja 
tasklist: szolgáltatások, alkalmazások, feladatok, szálak 
lekérdezése 

timeout: a parancsvégrehajtás felfüggesztése 

where: fájl beazonosítása, keresése paraméterek 
alapján 

whoami: aktuális felhasználó és jogainak azonosítása 
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UNIX héj 

Ha valaki natív UNIX típusú tojáshéjra vágyik Windows Server 
2003-as környezetben, annak a Services for UNIX jelenlegi, 
3.0-ás változatát javaslom, ugyanis Korn Shellhez és egyéb fi- 
nomságokhoz juthat. Bővebb info a [winunix] címen található, 
a termék elérhető jelképes összegért. Nem bírom megállni, 
hogy a GPL/GNU licenszelés alatti ingyenes eszközök forrás- 
kódjának letöltési címét ne közvetlenül ide másoljam be: 
ftp://ftp.microsoft.com/developr/lnterix/sfu30/gnu/ 

És még azzal merik vádolni az MS-t, hogy nem támogatja az 
open source mozgalmat... 


Radvánszki Gábor 
radvanszki.gabor€bcss.hu 
konzulens, MCP 

BCSS Kft. 


A cikkben szereplő, kiemelt [kulcsszo] használata: 


Lormmunicare necesse esti 


Használjuk erre 


es/ 


a legmegfelelőbb eszközt! 


A Microsoft Exchange a maga 110 millió felhasználójával magasan napjaink vezető üzenetkezelő és 
csoportmunka platformja. És hamarosan itt az Exchange 2003 (Titanium) az új verzió! Bátorfi Zsolt be- 
vezető cikke után vizsgáljuk meg közelebbről, hogy mit rejtenek a csillogó korongok. Áttérjünk? Vár- 
junk? Jobb lesz? Próbáljuk ki! Nézzük meg a gyakorlatban, hogy mi lakik a hangzatos név mögött! 


A jelen 


Tesztünk alanya egy kisvállalat — kedvenc téglagyárunk - egy 


telephellyel és pár tucatnyi felhasználóval. Kiindulási állapo- 
tunk egy Windows 2000 SP3 -- Exchange 2000 SP3 és nagyon 
szeretnénk eljutni mindkét termékkel 2003-ba. A rendszer fel- 
töltésére az Exchange Resource Kit loadsim nevű eszközét 
használtam, hogy a dolog életszerűbb legyen. Pontosabban 
annak a [loadsin] címről letölthető aktuális változatát. 
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Loadsim akcióban 


Ez a kis program alapvetően egy Exchange terhelésszimulátor, 
azonban jelen esetben az volt a feladata, hogy egy szűz rend- 
szerbe adott számú felhasználót, postaládát, nyilvános map- 
pát, a felhasználók postafiókjába üzeneteket, kontaktokat, 
megbeszéléseket generáljon, majd néhány millió elvégzett 
művelettel pár évnyi múltat adjon a rendszernek. 


Olvassunk! 


Mielőtt túlságosan hamar megfeszítenénk klikkelő izmainkat a 
setup.exe felett, azt javaslom, hogy dőljünk kicsit hátra, olvas- 
sunk és gondoljuk át, hogy mit is szeretnénk csinálni. 
Bár az Exchange 2003 még csak béta 2 fázisban van, máris te- 
kintélyes mennyiségű dokumentáció áll rendelkezésünkre. A 
teszt során egy in-place (eredetit felülíró) upgrade-et játszunk 
el, nézzük, mi kell ehhez: 

JA Minimum Windows 2000 SP3 

TH Minimum Exchange 2000 SP3 

H Az ADC szervereinken az Exchange 2003 ADC-nek 

kell(ene) futnia . 


Eddig meg is volnánk, ADC-t nem használunk, a többi rend- 
ben. Ismét egy rövidítés. Mi is az az ADC és mire való? Ennek 
megértéséhez tolassunk kicsit vissza az időben, egészen az 
Exchange 5.5-ig. Mi volt vajon a legfontosabb különbség az 
Exchange 5.5 és az Exchange 2000 között? 

A címtár. Az Exchange 5.5-nek bizony saját, külön címtára volt 
(Exchange directory). Ebben tárolta a felhasználók levelezéssel 
kapcsolatos attribútumait és saját konfigurációs adatait. Maguk 
a felhasználók egy másik címtárban laktak és egy Exchange 
directory-ban beállított csatlakozás segítségével találtak be a 
postafiókjukba. Teljesen jogosan merült fel a kérdés: kell ennyi 
címtár? Hiszen ugyanannak a felhasználónak az attribútumai- 
ról van szó, miért tároljuk egy részét itt, egy részét ott? Dupla 
címtár, dupla adminisztráció, dupla fejfájás. Valószínűleg 
Redmondban is így gondolhatták, mert az Exchange 2000-nek 
már nincs külön címtára, az Active Directory-t használja (Egy 
címtár mind felett... ). Szép dolog, de vajon mi a helyzet az 
együttéléssel? Kidobhatjuk az Exchange 5.5-öt? Szerencsére 
nem, segít nekünk az ADC. Segítségével kapcsolatot teremthe- 
tünk a két címtár között, és a megfelelő konfigurációs és fel- 
használói adatokat szinkronizálva lehetővé válik az együttélés, 
vagy migráció. Az Exchange 2003 CD-n egy - főleg felhaszná- 
lói visszacsatolások alapján — bővített és javított ADC található. 
Exchange 5.5-ről közvetlen frissítés Exchange 2003-ra nem le- 
hetséges. Ebben az esetben az Exchange 5.5 mellé kell telepí- 
tenünk egy Exchange 2003 szervert és Active Directory kon- 
nektor és az Exchange Server Deployment Tools segítségével 
lehet elvégezni a migrációt. 

A kompatibilitási mátrixot átnézve láthatjuk, hogy első lépés- 
ként az Exchange frissítése következik, mert az Exchange 2003 
— ugyan nem teljes funkcionalitással, de — fut Windows 2000 
operációs rendszeren, míg az Exchange 2000 — Windows 2003 
párosítás nem megfelelő. 


Az Exchange 


Támogatott Active Directory 
ezt 





telepíthető és futhat. . 
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Windows 
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Exchange 


. Nem szükséges Nem szükséges 





2000 SP2 Igen Nem igen Igen 
Ut 

ENSZ Igen Nem lgen 1gen 

mezét Igen (W2K SP3) Igen Igen (W2K SP3) Igen 
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Communicare necesse est! 
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Eltávolítandó komponensek 


Fontos tudnivaló, hogy — amennyiben telepítve van- 
nak — néhány Exchange-komponentt el kell távolíta- 
nunk a frissítés előtt. Ilyen például: 


Az Instant Messaging (a jövőben külön termékként fog 
megjelenni) 

Chat 

Key Management Server (Nincs már rá szükség. Hogy 
miért nem, az külön megér egy cikket) 

MsMail konnektor, ccMail konnektor 

a Mobile Information Server Exchange Event Sink kom- 
ponense. 
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Fúrógép, csavarhúzó, kalapács... 

Örömmel állapíthatjuk meg, hogy a fírissítésben alaposan ki- 
bővült eszközkészlet segít minket. A Microsoft Exchange 
Server Deployment Tools felkészített varázslókkal várja inst- 
rukcióinkat. 


fos azo ravsag Eschanat 5.5 and have fachanaz 5.3 Unarade 
zet epnmedtmá €sekánge to kove 





E Exchange Server Deployment Tools 


Ezeket az eszközöket futtathatjuk az Active Documentation- 
ból, ebben az esetben a dokumentáció lépésről lépésre vezet 
minket, és biztosabbak lehetünk benne, hogy a megfelelő pa- 
ramétereket adjuk meg. Command line eszközből is van bő- 
ven, a teljesség igénye nélkül egy kis ízelítő: exdeploy, 
dsscopescan, dcdiag, orgcheck, polcheck... 

Maga az Exchange 2003 telepítőprogram is változott. Például 
a telepítést végző felhasználónak az első szerver után nem 
szükséges az egész organizációban full exchange adminisztrá- 
tor jogosultság, elegendő az adott adminisztratív csoportra. 
Megjelent a /ChooseDC kapcsoló, ahol megadhatjuk, hogy a 
telepítés során melyik DC-t használjuk, és még számos válto- 
zás teszi könnyebben használhatóvá a telepítőt. 


Ágyazzunk! 


Az Exchange 2003-nak külön meg kell ágyazni - az Exchange 
2000-nél megismert módon. Az Exchange 2000 által módosí- 
tott Active Directory sémát tovább kell bővíteni, ha ezt elmu- 
lasztjuk, a következő üzenet hívja fel a figyelmet erre: 


rosoft Exchange Installation Wizard 


Component Selection 
Select and modííy components to fit your custom sokdtion. 





Cíck nthe lett column to specify the appropriate action for each component. 


Microsoft Exchange Installation wizard 


"[Domain?rep" switch vathin 
version of Setup, then you must wait for repication to complete, Consult your 
documentation for details. 


EI ÉOLGEDSÉTSE hete Eemássene bo corelétats segzlon or ács Dre-tory hos: 
not repkcated all the necessary permissions for the deleted tems. 





E Ne felejtsük el a sémát kibővíteni! 


A séma bővítésében természetesen segítenek varázslóink is, de 
én jobban szeretek belátni Óz köntöse mögé, így mondjuk azt, 
hogy: 

"CD meghajtó; :NSETUPNI386isetup /forestprep 

Majd: 


£CD meghajtó; : ISETUPNI386isetup /domainprep 


Exchange frissítés 


Az előkészítés után következhet a frissítés. A következő 
service-re van szükség ehhez: 

A .NET Framework 

JA ASP.NET 

A World Wide Web service 

A SMTP service 

A NNTP service. 


A .NET Framework és ASP.NET service-eket a telepítő Win- 
dows 2000-re automatikusan telepíti, azonban natív Windows 
2003 forest esetében ezek le vannak tiltva, nekünk kell enge- 
délyezni őket telepítés előtt. 

Téglagyári gépünkön azonban csak elindítjuk a frissítést, és a 
végén örülünk. 





cxCD meghajtó; :NVSETUPNI386isetup.exe 


4 Microsoft Exchange installation Wizard 


Component Progresz. 
The feloving components are now performing the actions you have selected 


7 Microsoft Search 

7 Microsoft Exchange 

b Microsoft Exchange Messaging and Collaboration Services 
Microsoft Exchange System Management Tools 





cBsek Next 








A frissítés után magasabb diszk aktivitás tapasztalható, a 
store.exe igen tevékeny. Ennek oka feltehetően az, hogy a ver- 
zióváltással változott a store.exe és az adatbázis szerkezete, és 
az adatbázis konverziója ilyenkor történik meg. Apropó 
store.exe: tehát maradt a jet/ese adatbázismotor. 


Mit találunk a szerverünkön a frissítés után? 
Egy Exchange 6.5-öt (Buid 6803.8): 


General I 


VAKOLAT 





a A Exchange 2003- 
Version 6.5 (Build 6803.8) — Echan g61ő.5 
Igen, az Exchange 2003 az Exchange 2000-hez hasonlóan, 6- 
os Exchange. A Nagy Váltás valóban várat magára az ugrás 
nem generációs. A dolog nem példa nélküli, gondoljunk csak 
a szép karriert befutott Exchange 5.5-re, ami az 5.0 gyermek- 
betegségeit kinőve évek óta kifogástalanul működik számos 
ügyfélnél. 

Az Exchange 2000 SP3-tól az Exchange 2003 beta 2-ig elké- 
szített 554 build-nek azonban meg van az eredménye, a ter- 
mék számos újdonságot tartalmaz. Ezek a módosítások első- 
sorban a felhasználói visszajelzések alapján történtek és ennek 
eredményeképpen valóban a termék használhatóságát javítják. 
A témáról az előző számban remek összefoglaló található, de 
az egyes témakörök külön-külön is megérdemelnek egy önál- 
ló cikket. 


Hová tűnt az M: meghajtó? 


Az Exchange 2000-nél az information store tartalmát M: meg- 
hajtóként elérhettük a fájlrendszeren keresztül is. Ez azonban 
sokszor bajt is okozott. Az egységsugarú rendszergazda bizony 
késztetést érezhetett arra, hogy például a jogosultságokat — 
még leírni is rémes — az M: meghajtón könyvtárakként látszó 
mailbox-okon fájlszinten módosítsa. Ezt az Exchange ,meg is 
hálálta" sok fejtörés okozva a helyrehozásra kiérkezett szak- 
embereknek. További potenciális hibaforrást jelentett, hogy a 
fájlszintű vírusvédelmet biztosító programok és a mentőszoft- 
verek az M: meghajtón különféle fájlszintű műveleteket végez- 
ve a levelezési adatbázis sérülését okozhatták. Jobb a békes- 
ség, az M: meghajtót elfelejthetjük. 

Mit tegyenek azok, akik az adatbázis fájlrendszer driver-ét 
megfelelően kezelő alkalmazást használnak, és szükségük van 
a fájlszintű elérésre? 

Az adatbázis tartalma fájlszinten továbbra is látható, azonban 
kicsit jobban el van rejtve. Az eléréshez szükséges névtér a kö- 
vetkező: 


NV.NBackofficeStorageNV 

A postafiókok listáját például a 

dir NWV.lBackofficeStoragelteglagyar.netimbx 
paranccsal nézhetjük meg. 


A , nagy piros gomb" és társai 


Az Exchange frissítés tehát sikerült, az Exchange már 2003-as, 
az operációs rendszer még Windows 2000. Az Exchange 


System Managert elindítva ismerős kép fogad, na- 
gyon hasonlít az Exchange 2000-ben megszokottra. 
Egy kis Exchange 2000 tapasztalattal könnyen el le- 
het rajta igazodni. 














] azon vew [6 5] Olmiee BBI E 
Tree] VAKOLAT 


First Organization (Exchange) 
A ef dobal Settings 

43 Internet Message Formats 
1 Message Delvery 

8 Wireless Services 











HijRecovery Storage Group 
Gijsecond Storage Group 





B A VAKOLAT 
a § Roting Groups 
E SZ First Routing Group 
B ág Folders 
E €8 Tools 
6?) Message Tracking Center 
CJ Malbox Recovery Center 
B CI Monitoring and Status 
(] Notficatk 
CI status 


E Exchange System Manager 2003 


Ha egy kicsit alaposabban szétnézünk, számos változást lá- 
tunk. Itt van például a wireless támogatás, ami belekerült a ter- 
mékbe: 


First Organization (Exchange) 
A £f Global Settings 
4€3) Internet Message Formats 









ES Recipient Policies d 
ra B All address tists Integrált mobilitás 


A termékbe integrált mobiltámogatás és a mobileszközök roha- 
mos fejlődése az Exchange szolgáltatásainak jóval szélesebb 
körű elérését teszi majd lehetővé. 

Újdonság a Oueue Viewer is: 














E A ,,nagy piros gomb" 


tt TE áWt áá ET d ns TE 
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" Használjuk erre a legmegfelelőbb eszközt! / 


Communicare necesse est! 


40 


Végre átgondolt eszköz készült a gueue-k kezelésé- 
re, egy helyen láthatjuk és kezelhetjük az SMTP és 
X.400 levelezési sorokat. Felhívnám a figyelmet a 
,Nagy piros gombra", ami különösen hasznos lehet 
abban az esetben, ha egy kedves worm próbálja 
levelek ezreit kipumpálni szerverünkön keresztül. Persze egy 
jól menedzselt rendszerrel ilyen nem fordulhat elő. Már csak 
azért sem, mert az Exchange 2003 továbbfejlesztett és bővített 
antivírus API-t, a VSAPI 2.5-öt használ. Ez az Exchange 2000 
SP1-ben megjelent VSAPI 2.0 utódja és lehetővé teszi többek 
között, hogy a mailboxot nem tartalmazó szerverek — például 
gateway, vagy bridgehead szerverek — is szűrjék az áthaladó 
forgalmat. 

A nyilvános mappák kezelése is sokat fejlődött. Az Exchange 
2000 esetében ez teljesen , automatikus" volt, és bizony néha 
megjelent az Exchange 2000 levelezési listán ,mindent jól 
beállítottam, mégsem replikálja a nyilvános mappák tartalmát" 
témájú levél. Szerencsére az Exchange 2003-ban van lehető- 
ség a replikáció manuális elindítására is, így ilyen esetben tud- 
juk noszogatni megfontoltan replikáló szerverünket. 


Az eszközök között megjelent a Mailbox Recovery Center, ami 
tulajdonképpen az Exchange 2000 CD-n található mbconn.exe 
nevű eszköz bővítése és integrációja a System Managerbe. 
Miért van erre szükség? 

Képzeljük el, hogy megtörténik a katasztrófa. Az Exchange 
szerverünkre rászakad az ég. Enyhébb esetben leég, beázik, 
felrobban, vagy ellopják. A lényeg az, hogy teljesen és végle- 
gesen működésképtelen lesz. Mit tesz ilyenkor a jól felkészült 
üzemeltető? Előveszi a tűzálló széfből a katasztrófatervet és 
megnézi, mi ilyenkor a teendő (és persze azonnal hívja a Pre- 
mier Supportot €). Tegyük fel, hogy a címtár nem sérült — ha 
igen, az egy másik cikk lesz —, viszont a levelezőszerver telje- 
sen megsemmisült. A katasztrófaterv tartalmazza, hogy ilyen 
esetben honnan kell előrántani egy megfelelő vasat, milyen 
beállításokkal kell feltelepíteni rá az Exchange-t (a katasztrófa 
előtti állapot) és pontosan hol található a legutolsó Exchange- 
mentés. Az utasításokat követve visszatöltik a mentést, és meg- 
próbálják mountolni az adatbázist. Ha jó a terv és pontosan 
hajtották végre, ez sikerülni is fog, azonban a postafiókokat 
megnézve sok piros keresztet fognak látni: 


8 Sonsole Window ! Help 
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[DD F24oguzbaa VAKOLAT 


[BdMzpbbi33s3s VAKOLAT —— TEGLAGYARjdstvan 54610 
[Ddmapbbkfasa VAKOLAT —— TEGLAGYARjdistvan 51004 
[BdMapbbkfbaa VAKOLAT —— TEGLAGYARIdistvan 57202 
[dd Mapbbkfcaa VAKOLAT TEGLAGYARIdistvan 46551 
[B Mzpbbinasa VAKOLAT TEGLAGYARIdstvan 53926 
[d Mapbbknbsa VAKOLAT TEGLAGYARdistvan 54203 
[d Mzpbbkncaa VAKOLAT —— TEGLAGYARdstvan 44472 
[d Mzpbbkvasa VAKOLAT TEGLAGYAR[distvan 49718 
9 SMTP (VAKOLAT -(B289... NT ALUTHORITYISYSTEM o 

d) SystemMatbox(B2891C. ,. NT AUTHORITYISYSTEM 393 


7 B Rnntina Grone 


B Vajon sikerült a helyreállítás? 


Nem kell rögtön a gyógyszeres szekrény felé nyúlni, nincs 
nagy baj, a helyreállítás egyik lépésében a címtárból el kellett 
távolítani a ,halott" szerver bejegyzéseit. Ezért ezek a mailbox- 
ok ,árván" maradtak. Az adatbázisban jelen vannak, de a cím- 
tárban rájuk vonatkozó bejegyzés nem megfelelő. Helyre kell 
hozni ezt a hivatkozást, vagyis újra kell csatlakoztatni a posta- 
fiókokat: 


B 
Csatlakozzunk? 





Aim2obbkncaa VAKOLAT 


TEGLAGYAR 


Ezt megtehetjük egyesével a postafiókokra kattintva, de több 
száz felhasználónál ez nem túl szórakoztató időtöltés. Ilyen 
esetben nagyon fogjuk szeretni a Mailbox Recovery Center-t, 
mert az adott mailbox store-t hozzáadva megkeresi nekünk a 
postafiókokhoz tartozó felhasználókat és létrehozza a szüksé- 
ges hivatkozásokat. 

Szintén a helyreállításban nyújt segítséget a Recovery Storage 
Group. Ez egy speciális storage group, amibe visszatölthetjük 
az azonos adminisztratív csoportból származó adatbázisain- 
kat. Az adatbázist ide visszatöltve az Exmerge segítségével 
visszamozgathatjuk a szükséges adatokat a megfelelő helyre. A 
Recovery Storage Group a felhasználók számára nem érhető 
el, így üzem közben is elvégezhető a visszaállítás. Miért is jó 
ez nekünk? Tegye fel a kezét, akihez érkezett már olyan kérés, 
hogy egy postafiók 1-2-3 héttel ezelőtti tartalmát kellene 
visszaállítani! Vagy a főnöknek nagyon szüksége van egy olyan 
levélre, amit 2 hónappal ezelőtt kítörölt... Mi ilyenkor a teen- 
dő, ha nincs postafiókszintű visszaállítást támogató mentő- 
rendszerünk? Recovery szervert telepíteni, oda visszatölteni a 
megfelelő mentést, majd Exmerge segítségével kinyerni a pos- 
tafiók tartalmát. Ez nem fél órás mutatvány. A Recovery Storage 
Group segítségével viszont igen. 

Az újdonságok listája meglehetősen hosszú, terjedelmi okok 
miatt nem lehet célom ezeknek a tételes ismertetése. Egy vál- 
tozást azonban még megemlítek, mert már nagyon időszerű 
volt. Ez az , Out of Office" üzenetek kezelése. Gondolom min- 
den levelezőlista tagnak ismerős, mikor a szabadságon lévő fi- 
gyelmetlen listatagok minden listára érkező levelet egy ilyen 
üzenettel hálálnak meg. Mostantól kezdve biztosak lehetünk 
benne, hogy ők nem Exchange 2003-at használnak, mert 
Exchange 2003 esetében csak akkor megy el az ,Out of 
Office" automatikus üzenet, ha a felhasználó szerepel a To: 
vagy a Cc: mezőben, tehát listás levelek esetében nem. 
Folytassuk a migrációt a Windows írissítésével! 


Windows 2003 upgrade 


A Windows 2003 telepítéséhez az adprep segítségével elő kell 
készíteni az Active Directory erdőt és domaint. Az adprep 
használatának előfeltételeiről a 0331161-es cikk nyújt bővebb 
információt. A következő kapcsolókat használhatjuk: 


D:NI386-adprep /? 
The syntax of the command is: 
adprep ccmdsi [option] 
Supported cemd;: 
/forestPrep Update forest-wide information 
Must be run on the schema role 
master 
/domainPrep Update domain-wide information 
Must be run on the infrastructure 
role master 

Must be run after /forestPrep is 
finished 
Supported [option]: 

/noFileCopy adprep will not copy any file from 
source to local machine 
adprep will suppress the 

Windows 2000 service pack 2 


/nosPWarning 


E MA Ba E 





reguirement warning during 
/forestprep 


Az erdő előkészítése: 


SCD meghajtó: :NI386Vadprep /forestprep 


Majd kapunk egy figyelmeztetést: 


ADPREP WARNING: 

Before running adprep, all Windows 2000 domain 
controllers in the forest should be upgraded to 
Windows 2000 Service Pack 1 (SPl) with OFE 265089, 
or to Windows 2000 SP2 (or later). 

OFE 265089 (included in Windows 2000 SP2 and 
later) is reguired to prevent potential domain 
controller corruption. For more information about 
preparing your forest and domain see KB article 
0331161 at http://support.microsoft.com. 

IUser Action] 

If ALL your existing Windows 2000 domain 
controllers meet this reguirement, type C and then 
press ENTER to continue. Otherwise, type any other 
key and press ENTER to guit. 


Mivel domain kontrollerünk megfelel a feltételeknek, 


C cSENTER2 


Megtörténik a séma frissítése: 


Opened Connection to VAKOLAT 

SSPI Bind succeeded 

Current Schema Version is 13 
Upgrading schema to version 30 
Connecting to "VAKOLAT" 

Logging in as current user using SSPI 
Importing directory from file 

"c: WINNTYSystem321sch14.1d£" 

Loading entries 
111 entries modified successfully. 





Adprep successfully updated the forest-wide 
information. 


Majd: 


xCD meghajtó; :NVI386Vadprep /domainprep 


A sikeres adprep után indíthatjuk a frissítést: 


cSCD meghajtó: :VI386íwinnt32.exe 


4 Windows 


Ö 
Cse ee 
Ci Welcome to Windows Setup 


ereket 
e Wwhehtpe et mutálaten do vas mart to peta? 


tredalaton Tye [dose ecszmsendog 7 Z] 


Cl at elesak 


TE), Dezatssztant ssmezetysogatryan 
B szesmaz 
lopna tszents roz ieled págvat és 
kezatzs mata 


NN 
orrot eti 
vmésék 


DJ) DumgSeha ta ramultor vaz azeen tő 99 
tar tor atem tecordk md for tbe Corouátt to 
ta évet sevtráltmez 


Metz sákalása 
ESC key. 


E Windows 2003 upgrade 
A frissítés a licenszkulcs megadása, újraindulás és egy kis vára- 
kozás után be is fejeződik, közben természetesen roppant 


hasznos dolgokat olvasgathatunk az új termékről: 


at EPRg w 





Megérkeztünk? 


A frissítést látszólag sikeresen megtörtént. Ellenőriz- CA 


zük az operációs rendszerünk verzióját: 


Automatic Updates ] Remote 
Computer Name l Hardware 
System 
Microsoft Windows Server 2003 
Enterprise E dítion 
c:VWver 


Microsoft Windows [Version 5.2.3763] 


Éljenzés, görögtűz, mindkét termékkel megérkeztünk 2003-ba, 
a feladatot elvégeztük! 

Ezzel az utolsó lépéssel hazai pályára helyeztük az Exchange 
2003-at, Windows 2003 operációs rendszeren futtatva kapunk 
teljes funkcionalitást. A teljesség igénye nélkül nézzük át, hogy 
mivel lett okosabb az Exchange 2003 szerverünk: 


A Shadow Copy Backup: A Windows Shadow Copy 
service segítségével a mentés terén új lehetőségeink 
nyílnak. Segítségével konzisztens pillanatfelvételt ké- 
szíthetünk egy kötetről. (Fontos téma, szintén megér 
egy cikket.) 

A Outlook http access (RPC over http): Az IIS 6.0 és a 
Windows 2003-ban található Windows RPC Proxy 
service lehetővé teszi, hogy az Outlook 2003 és az 
Exchange 2003 közötti kommunikáció http, vagy https 
protokollokon keresztül történjen. 

A Fejlettebb clustertámogatás: Mindkét termék fejlesztett 
és bővített clustertámogatással rendelkezik. Aki kinőtte 
a jelenlegi 2 vagy 4 node-os clusterét, annak van egy jó 
hírem: ezentúl építhet 8 node-os clustert! A függőségi 
viszonyok ésszerűsítése jelentősen jobb failover időt 
eredményez, vagyis probléma esetén az Exchange 
szolgáltatásai percekkel rövidebb idő alatt elérhetőek. 
Ez a javulás igen jelentős, ha figyelembe vesszük, hogy 
Windows 2000 - Exchange 2000 párosítás esetén egy 
átlagos failover — felhasználók számától függően — 3-8 
percet vett igénybe. Végre a Kerberos az alapértelme- 
zett autentikációs protokoll az Exchange virtuális szer- 
vereknél. Exchange 2000 esetében ez az NTLM volt, 
mivel a Windows Cluster service csak a Windows 2000 
SP3 után volt képes Kerberost használni. 


Eddig a szerveroldallal foglalkoztunk, vajon mi újság a vége- 
ken? Egy levelezőrendszernek alapvetően a felhasználók igé- 
nyeinek kell megfelelnie. Az Exchange 2003 fejlesztésekor is 
ez volt a legfontosabb szempont, a legnagyobb fejlődés a 
kliensoldalon és a klienselérés területén történt. Teljesen megú- 
jult az Outlook Web Access, funkcionalitását tekintve felveszi 
a versenyt a szintén számos újdonságot tartalmazó Outlook 
11-gyel. De ez már egy másik történet, és egy másik cikk. Ez- 


zel folytatjuk. . 


Détári István 
istvan.detari€ogetronics.hu 
MCSE, MCSA, CCNP 
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"ba Dupla KU 


PKI ikonok az Outlookban 


K: Egyre gyakrabban küldök digitálisan aláírt vagy titkosított le- 
velet Outlookkal. Ilyenkor minden esetben az üzenet biztonsá- 
gi beállításainál kell pár pipát tennem, ami az alábbi képen is 
látszik. 


Adatvédelmi beállítások HEC 2d 


TF Küldés nyilt szöveggel aláírt üzenetként 


FF Kérjen visszaigazolást az üzenet biztonságos voltáról 





zAutomatikusz -] Beállítások megváltoztatása. .. I 
Biztonsági címke 


Házirendmodul; [dnincsz -] Beáltás. 
[ d 


Besorolás; 





Biztonsági szint 
megjelölése: 











E Üzenetek titkosítása és digitális aláírása 


Hogyan lehet megoldani, hogy gyorsabban tudjak egy-egy le- 
velet digitálisan aláírni? 


V: Ha az Outlookot a biztonsági beállítások közt (Eszközök 2 
Beállítások 2 Adatvédelem) az alábbi képen is látható módon 
állítjuk be, akkor minden kimenő üzenet alapértelmezésként 
digitálisan aláírt és titkosított is lesz. 





Hi 





levél 
F TERE t kesett sra tzerátásől sÉ 


IF Digitális aláírás hozzáadása a kimenő üzenetekhez 








Alapértelmezett beállítás: I -] Beálítások... ] 


aláíráshoz és a titkosításhoz használható parancsokat. Az 
alábbi ábra talán segít a keresésben: 


(31 
Eszköztárak Parancsok ] Beálítások ] 


AES ELNE ER eszköze  BlNGgY Kiel Na V re Ke egérlőti 
sel T ESEL eS tek et ee e er oeszádpanet 


Parancsok: 

(gj Beállítások... 
LA Betűméret 
6 ü Üzenet tartalmának és és ; melléklete: 










. Üzenet digitális aláírása 
ea Microsoft Outlook sú. 





Kijelölt parancs: 


Leírás I Kijelölés módosítása 1 





al Bezárás 


E A digitális aláírás és a titkosítás elrejtett ikonjai 








Figyelem! 

Hiába kutatunk a megfelelő gombok után, ha az alapértel-me- 
zett levélszerkesztőnk a Word. Ilyenkor nem bukkan fel a ka- 
tegóriák közt a Szokásos (Standard), és nem tudjuk használni 
ezeket az ikonokat. 

A WordMail egyébként teljesen , üti" ezeket a gombokat, tehát 
még ha cselesen fel is tesszük őket a Word átmeneti lekapcso- 
lásával, amint visszakapcsoljuk, a gombok eltűnnek. De foly- 
tassuk a lépéseket! 


4. Ha rátaláltunk a listában a parancsokra, csak ki kell őket 
húzni az egérrel a levél eszköztárára. Tehát NEM az 
Outlook fő eszköztárára, hanem a levélére! 


Így néz ki a végeredmény: 


























Biztonsáaos tartalom 


EJ Minden kimenő levél aláírása és titkosítása 


Ez a megoldás azonban a másik végletet jelenti, mert ha nem 

mindenhova küldünk titkosított és/vagy digitálisan aláírt leve- 

leket, a pipákat a leveleknél egyenként ki kell szedni. 

Ennél jobb megoldás, ha a titkosításhoz és aláíráshoz szüksé- 

ges ikonokat megjelenítjük az eszköztáron. Nézzük lépésről 

lépésre: 

1. Nyissunk egy új levelet 

2. A levél Eszközök 2 Testreszabás menüjéből válasszuk a 
Parancsok tulajdonságlapot. 

3. A baloldali kategóriák közül a Szokásosat (Standard) kell ki- 
választani, és a jobb oldalon meg kell keresni a digitális 














E Felkerültek az eszköztárra az aláírásra és titkosításra 
szolgáló gyorsítógombok! 


Ezentúl az eszköztárra kirakott ikonok segítségével gyorsabban 
tudjuk aláírni és titkosítani az üzeneteket, mert a két kis ikon 
ott lesz a fejlécen akkor is, ha új levelet írunk, de akkor is, ami- 
kor válaszolunk egy levélre, vagy épp továbbítjuk azt. 
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RA .Net és a Tablet PL 


Miért fontos, hogy a Tablet PC a .Net keretrendszerre épül és a felhasználó számára 


milyen haszonnal jár a beépített .NET infrastruktúra? Hogyan illeszkedik a táblás mo- 
dell a .NET stratégiába? A Microsoft PressPass kérdéseire Vic Gundotra, a Platform 
Strategy igazgatója és Alex Gounares, a Tablet PC vezető tervezője válaszolt. 


Gundotra szerint ahhoz, hogy megértsük, miért izgalmas a 
Tablet PC, érdemes előbb egy pillantást vetnünk a.NET vízióra. 
Egyszerűen fogalmazva a .NET olyan platform, amely kapcsola- 
tot teremt különböző rendszerek között. Ez talán túlzott egysze- 
rűsítésnek hangzik — mondja Gundotra —, programozói szem- 
mel nézve azonban a különböző üzleti megoldások integráció- 
ja, az ügyfelek és a vállalkozások közötti átjárhatóság megte- 
remtése rendkívül költséges és bonyolult feladat. Az XML Web 
Services szabványos elemeire épülő .NET keretrendszer azon- 
ban segít a költségek csökkentésében, az eltérő rendszerek 
összekapcsolásában, együttműködésében. A Tablet PC azért te- 

" kinthető a.NET-kész kliensek zászlóshajójának, mert a .NET ke- 
retrendszer az operációs rendszer része. 
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Miért fontos a felhasználó számára beépített .NET inífrastruktú- 
ra? A .NET keretrendszer telepíthető ugyan egyedi PC-kre — vá- 
laszolta Gundotra —, de ezzel a feladatnak még nincs vége. Ám 
ha az alkalmazottak Tablet PC-t használnak, a beépített .NET 
keretrendszer révén minden egyes gép előtt nyitva áll a .NET 
infrastruktúra minden lehetősége. Látványosan könnyebb lesz 
a szabványos 

Tablet PC-s alkalmazások bevezetése is, hiszen azokat csupán 
el kell helyezni a webszerveren, majd úgy beállítani a felhasz- 
nálók Tablet PC-it, hogy erre mutassanak. A Tablet PC ezután 
automatikusan letölti és elindítja az alkalmazást. 





Gounares szerint a jövőben mind a horizontális, mind a verti- 
kális alkalmazásokban az eddiginél nagyobb szerepet kaphat a 
kézírásos adatbevitel és a képállományok kommentálása. Ve- 
gyünk például egy biztosítótársaságot, amelynél kézírással ki- 
tölthető formanyomtatványokat vezetnek be. A biztosítási ügy- 
nök digitális fényképet csatolhat a kárfelvételi jegyzőkönyv- 
höz, a képen pedig digitális tintával bekarikázhatja az autón 
keletkezett sérüléseket. Az ilyen, testre szabott alkalmazások 
kifejlesztése és bevezetése a .NET keretrendszer jóvoltából 
egyszerűbb, mint valaha. 
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Executíve Summary 
fuvtaa lörnéscálaény Ér tha ist fc var hatra bona ikazmastcaláy névláső 
due to significant productivity gains resulting Érom nev mani 
processes and employce training New product development teams are 
ahead of schedule and report early product performance has excceded their 
inátial projections. These teams have made significant progress and we 
expect to meet our launch desdhne on ume and under budget. Analysts 
projechons for our new product launch have been uruformly positive 
We have completed an exhavsve analysis 0f competitive product offerings 
and arc confident that our new product will gamer a significant porhon of 
the market upon its release. No other competitor provides such a broad 
product line. i 
We have established key partnerstups with sakién of the nine largest 
distnibutors of our product in the United States. We have also begun 
negotiations with major international distribution firms and expect to 
leverage our key partnerships and the breadth of our prodvet line to reap 
economies of scale in distribution 
Our new guality control inspection program has resulted ín a 35 reduction 
in materials costs. Our streamlíned manufacturing process has produced a 
similar reduction ín Work in Process (WIP) inventory. 


Our cash tő cash conversion eyele is now at 45 Úgys 
financial investments have returned an averag 


feexpect to continue our success into the next year 


Minthogy a .NET keretrendszer a Visual Basictől a C-4-4-ig szin- 
te valamennyi programnyelvet ismeri, minden fejlesztő 
ugyanazokat a programozói könyvtárakat használhatja, ily mó- 
don a fejlesztés olcsóbbá és egyszerűbbé válik. Ahhoz - tette 
hozzá Gounares -, hogy egy, a .NET-re épülő alkalmazáshoz 
kézírás-felismerési támogatást készítsen valaki, mindössze két 
programsort kell megírnia. j 

Hogyan illeszkedik az írótáblás modell a Microsoft .NET stra- 
tégiájába? — tette fel a kérdést a PressPass. Nos, Gundotra sze- 
rint a Tablet PC legfontosabb újdonsága, a kézírásos adatbevi- 
tel számos esetben sokkal természetesebb és hatékonyabb a 
billentyűzetnél. Ám a Tablet PC a felhasználó környezetére is 
hatással van. Ha egy tárgyaláson valaki hagyományos laptopot 
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.Net és a Tablet P[/7 


A 


; vesz elő, és gépelni kezd, miközben az ügyféllel be- 

szélget, óhatatlanul elvonja a figyelmét. Ezzel szem- 
ben, ha a szemébe nézve jegyzetel, az ügyfél úgy ér- 
zi, rá összpontosul a figyelem. 
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—--Ongnal Message — 
From: ándrew Don 

Sent: Monday, July 22, 2001 7:10 AM 

To: Andrew Ouon 

Subject: Budget review 

Here is the final revston tő next years budget for your remevy 
Thanks, 

Andrew 
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Korábban a méret volt a hordozható gépek legfőbb kritériumai- 
nak egyike. A Tablet PC esetében az adatbevitel — azaz a kéz- 
írás- és beszédvezérlés lehetősége — legalább ilyen fontos. 
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ACME Products Performance Review 
Executive Sammary 


Revenue Projectionz for the next fiscal year have been dramatically remzed due to 
significant productivity gams resulting rom new manufacturing processes and employee 
traning New product development teams are ahead of schedule and report early product 
performance has exceeded their inihal projecons "These teams have made agnácant 
Progress and we expect to meet our launch deadine on time and under budget Analyst" 
Projections för our new product launch have been unformly positive 


"We have completed an exhaustive analysis of competitive product oferings and are 
confident that our new product will garner a signiőcant portion of the market upon ts 
release. No other competitor provides such a broad prodhet ne. 


We have estabhshed key partnershipe wath seven of tbe nine largest distributor: of our 
product in the United States We have also begun negotiahons with major intemational 
distnbution firms and expect to leverage our key partnerthups and the breadth of our 
Product hne to reap economies of scale in diztnbution 


Our new gualíty control inspection program has resulted in a 3996 reduction ín materials 
tosts, Our streamined manufacturing process has produced a similar reduction m Work. 
ín Process (WIP) inventory. 


Our cash to cash conversion cyele 1 now at 45 days. Our short term financial nvestments 
have returned an average of 8.596. 


We expect to coninme our mecess into 
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A .NET vízió lényege a rendszerek összekapcsolása, ennek pe- 
dig fontos része a mobil eszközökkel való integráció. E filozó- 
fia szerint — fejtegette Gundotra — egyre több érték a hálózat 
perifériáján képződik. Minél egyszerűbbé és hatékonyabbá vá- 
lik a kapcsolat a Tablet PC-hez hasonló eszközökkel a külön- 
böző rendszerek és hálózatok között, annál kevésbé lesz értel- 
me hálózati végpontokról beszélni. Gondoljunk csak bele an- 
nak a felhasználónak a helyzetébe, aki akárhonnan, akármikor, 
akármilyen eszközzel kapcsolódni szeretne a vállalati adatbá- 
zishoz! Amennyiben ez a feladat szabványos módon megold- 
ható, megoldódik a vállalatok és belső rendszereik közötti kap- 
csolódás problémája is. Amennyiben az XML webszolgáltatá- 
sokat megfelelően használják, és köré olyan programozási mo- 
dellt építenek, mint a .NET keretrendszer, mindazokat a prob- 
lémákat elfelejthetjük, amelyekre elosztott számítástechnika 
néven szokás utalni. A .NET decentralizálja és ellaposítja a há- 
lózatot, így többé nem lesz jelentősége annak, hogy a hálózat 
végpontján vagy a kellős közepén vagyunk-e éppen, mert az 
információkhoz és a szolgáltatásokhoz mindenki egyformán, 
szabványos módon férhet hozzá. Korábban — tette hozzá 
Gounares — a hálózat perifériáján meg kellett elégednünk a rá- 
diótelefonokhoz hasonló egyszerű szerkezetekkel. Mostantól a 
hálózati végpont is lehet teljes értékű PC. 

Ám hogy nem csak elméletekről van szó, arról orvosok, gyógy- 
szergyártó cégek, kórház-informatikai szállítók és szoftverfej- 
lesztők Tablet PC-vel szerzett tapasztalatai tanúskodnak. Mint 
arról a San Diegóban rendezett 2003 Healthcare Information 
and Management Systems Society (HIMSS) konferencián és 
kiállításon beszámoltak, a nagyjából kórlap méretű Tablet PC 
az orvosok számára a jegyzettábla és az egérrel, billentyűzet- 
tel, íróvesszővel egyaránt kezelhető, valós idejű, vezeték nél- 
küli adatkapcsolatot nyújtó számítógép előnyeit egyesíti. 

A San Franciscói Stentor kórház-informatikai cég elkészítette 
orvosi információ- és képkezelő rendszerének Windows XP 
Tablet PC kiadásra átdolgozott változatát. Az iSite Enterprise 
segítségével az orvosok egy szempillantás alatt lehívhatják a 
kórházi hálózatra kapcsolt számítógépekről a páciensről tárolt 
adatokat, felvételeket a tablet gépre. 

S mint arról egy orvosgyakornok beszámolt, számára a Tablet 
PC olyan, mintha az íróasztalát tartaná a hóna alatt: megnéz- 
heti a laboreredményeket, a kórelőzményeket, vagyis mindazt, 
amire a kezelés során szüksége van, s mégsem akkora súlyt 
magával cipelnie, mint korábban, amikor az összes kórlapot 
magával hordta a nagyvizitre. 


Kelenhegyi Péter 
kelenhegyiGaxelero.hu 






Annyival előbbre 
járunk, hogy 

a világon mindenki 
ezt szeretné! 
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INGRAM Ingram Micro Magyarország 
1139 Budapest, Fáy utca 4. 
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. Adatbázislekérdezések 
. optimalizálása 


ACADEMIA 


Az utóbbi időben több szaktanácsadási felkérést kaptunk, amelyben gyengén muzsikáló, lassú adatbázisok miatt 
elégedetlenkedtek egyes alkalmazások felhasználói. Ezért úgy gondoltuk, itt az ideje, hogy alaposan körüljárjuk 
a témát. 


Mit várhatnak a tanfolyamtól? 
Az optimalizálási tanfolyam törzsanyagát a 2073 - Programming a Microsoft SOL Server 2000 Database hivatalos 


Microsoft tanfolyam anyaga alkotja. Ez az tanfolyam megismerteti a leendő SOL programozókat az SOL Server 
felépítésével, és a tananyag fele eleve optimalizálással, indexeléssel foglalkozik. Mi minden egyes témakörnél a 
teljesítményhangolási kérdésekre helyezzük a hangsúlyt. A tanfolyam példáit kiegészítjük további élő adatbázi- 
sokból kivadászott lekérdezésekre, amelyeken a hallgatók oktatói segédlettel nagyságrendi gyorsulásokat 
érhetnek el. 


Kezdési időpont: 2003. május 26. 

Oktató Soczó Zsolt (MCSE, MCSD, MCAD, MCDBA, MCT) 

Szükséges előképzettség: az SOL nyelv ismerete mindenképpen fontos, mert ezt részletezni nem lesz időnk 
a tanfolyam során. 

Cím: NetAcademia Kft. 
Telefon: 472-1214 :. Fax: 472-1215 . http://www.netacademia.net 

















a dámogató Project 2002 Professlonal 
ja-a Microsoft, mely segítségével és a köz- 
"a, ponti nyilvántartást és kiszolgálást biztosító 
"Project 2002 Server termékkel együttműködve 

teljeskörű nagyvállalati, projektirányítási, terve- 
zési és döntéshozási feladatok végezhetők el, és 
annak adatai bármikor, bárhonnan hozzáférhe- 


vezési eszköz birtokában csökkenthet 
ségek és javítható a termelékenység, ál 
reségnövekedést eredményez. A Mi 
Project 2002 Standard minden eddigjfé 
szerűbbé teszi az ütemezések és erőfórrásol 
kezelését, a projekt állapotának közlését és a: 
projekt adatainak kimutatását. b 


A N b ú 


Microsoft Project 2002 felhasználói kurzusok 
Az érdeklődők kétnapos, intenzív tanfolyamok keretében ismerkedhetnek meg a Microsoft Project 2002-es verzióinak használatával. 


Rugalmas időbeosztás 

Megpróbáltuk figyelembe venni, hogy a cégek dolgozóikat nem tudják nélkülözni hosszabb időre, ezért a tanfolyamokat Intenzív, egész 
napos formában hirdettük meg, délelőtt 9.00 és 16.00 óra között. A tanfolyamok díja az oktatás és a tananyagok mellett az étkezést is 
tartalmazza a kurzus napjaira. 


Project 2002 Professional és Server - testreszabott oktatások 
Oktatóközpontunkon kívül, a megrendelő telephelyén, kihelyezett formában (vidéken is) is vállaljuk az adott cégprojektekhez kapcso- 
lódva tanfolyamok vagy konzultációk megtartását és lebonyolítását, különös tekintettel az összetett, Project 2002 Professional és 
Project 2002 Server használatával és bevezetésével kapcsolatos témákban. Ezt követően igény esetén további utólagos támogatást 
és szaktanácsadást is nyújtunk. 


Tervezze üzleti folyamatait Microsoft Project 2002-vel! 





? 203-0304/3040 www.szamalk.hu/tisza 1115 Budapest, Etele út 68. 
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PKI"-Workshop 


rendszergazdáknak 


NETACADEMIA  B7INETIOCK 


közös szervezésésben 





GEE Flektronikus aláírás használata 

GEHE ssI, IPSec, EFS, S/MIME a gyakorlatban NI 

GHZ Ajándék kulcstároló eszköz és NetLock j 
tanúsítvány ! 

CSI 1 


Smart Card Logon 


! 
Í 
! 


j 
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Legyen az elsők között! 





Public Key Infrastructure, a nyílt kulcsú titkosítás köré, annak segítségével készített alkalmazások összessége 
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PKI-Workshop 


Átfogó tudás az elektronikus aláírás és titkosítás vállalati szintű alkalmazásához. 


A kétnapos tanfolyamon minden tudást, tapasztalatot és eszközt (USB token), továbbá a 
szükséges elektronikus tanúsítványokat átadjuk hallgatóinknak, akik a megszerzett gyakorlat 
.! birtokában fel tudják készíteni a technológia használatára azokat a munkatársakat, akiknek 
.! már ma szükségük van elektronikus aláírásra és adataik titkosítására. 


Előadók: 


Fóti Marcell, NetAcademia (kriptográfia, Smart Card Logon) 
Boromisza Zsolt, NetLock (kulcstároló eszközök, kulcsok, tanúsítványok) 
Fülöp Miklós, NetAcademia (Certificate Authority, SSL, IPSec, S/MIME stb.) 


Dr. Mayer Erika, Páneurópa Jogász Unió (az elektronikus aláírás jogkövetkezményei) J 


Témakörök: 


e Mi az a kriptográfia? Hogyan működik a titkosítás? 

e Mi a kulcspár, a tanúsítvány, mi a szerepe az intelligens kulcstároló eszközöknek? 
e Szimmetrikus algoritmusok (DES, 3DES, AES) 

e Nyílt kulcsú algoritmusok (Diffie-Hellmen, RSA) 

e Hash (MD4, MD5, SHA-1) 

e Az X.509 tanúsítványok szerepe és használata 

e Hitelesítésszolgáltatók. A hierarchia felépítése 

e Kulcstároló eszközök: intelligens kártya és USB Token 

e Bejelentkezés tanúsítvánnyal (Single Sign On) 

e SSL, S/MIME, HTTPS 


e Virtuális magánhálózatok. 


Jogi blokk: 


Az elektronikus aláírási törvény célja, következményei, a végrehajtási rendeletek. 
Jogkövetkezmények, és a szükséges feltételek megléte. 
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Ajándék! Hallgatóink a tanfolyamon használt kriptográfiai eszközöket a tanfolyam után 


megtarthatják, és - a mellékelt NetLock tanúsítványokkal - hiteles elektronikus aláírást és 
nyílt kulcsú titkosítást használhatnak! 


Aláíró és titkosító kulcsok 
tárolása USB-tokenen 


4 NetLock B-osztályú ! 
tanúsítványpár! IN 
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! 
A tanfolyam kezdete [/Tinssi Bővebb információ Ár(F [7 


2003. május 19-20. 
2003. június 16-17. 
2003. augusztus 18-19. 


http://www.netacademia.net/workshop/PKI ! 
Telefon: (1) 472-1214 1 





Jelentkezés weben: ! 
e http://vww.netacademia.net/workshop/pki 


Jelentkezés faxon (472-1215) az alábbi adatok megadásával: 


e cégnév e hallgató(k) neve(i) 
e számlázási cím e e-mail 
e fax, telefon e időpont 
A tanfolyamok helyszíne j 





A NetAcademia Kft. világörökségi környezetben várja hallgatóit Budapesten az ) 
Andrássy út 62-ben! 





Megközelíthető az alábbi tömegközlekedési 
eszközökkel: 


e a Milleniumi kisföldalattival (Vörösmarty utca) 
e 4-es és 6-os villamossal (Oktogon) 
e vonattal (a Nyugati pályaudvartól 10 perc séta) 


Ingyenes parkolási lehetőség a Felvonulási téren. 


. További elérhetőségeink: 

(Telefon: 1/472-1214 

Fax: 1/472-1215 

E-mail: infol(Dnetacademia.net 

! Weblap: — http://www.netacademia.net 
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További tanfolyamaink rendszergazdáknak: 


áttérés 

A 2270-as sorszámot viselő tanfolyam az egyik legko- 
molyabb anyag a Microsoft kínálatából. Összetettségére, L£ 
átgondoltságára jellemző, hogy négy (!  MCP-vizsga 
felkészítő anyagaként ajánlják. 






W2003 - Windows 2003 Server Expert Workshop 
Szakítson időt a Windows 2003 újdonságainak felfedezésére! Nálunk 


összeszedni! 


:. Témakörök: 


e Az Active Directory újdonságai 

e A Group Policy újdonságai 

e Fejlesztői újdonságok rendszergazdáknak 
e Rendszerújdonságok 

e Biztonsági újdonságok 

e IIS 6 újdonságok 


SETUP - Felügyelet nélküli telepítés 

A tanfolyamot rendszergazdáknak, üzemeltetőknek ajánljuk. 
Automatikus telepítési változatok. A RIS és a PXE indítókör et 
nyezet. Válaszfájlok patkolása, OEM eszközmeghajtók 
telepítése, , idegen" merevlemez-vezérlők. Alkalmazások telepítése. 


I 
", Ha további rendszergazdai vagy fejlesztői tanfolyamainkra is kíváncsi, 


kérje teljes körű, ingyenes tanfolyami katalógusunkat! 


H-1062 Budapest, Andrássy út 62. e Tel.: 1/472-1214 s Fax: 1/472-1215 
E-mail: info(rDnetacademia.net e http://vwww.netacademia.net 








TSZZZEZET TETEMET ENS TEK MEOE TORT EZEKET ESNEE ZT ETETETT EE TSZ TETSZETT TOZTEZT NSZ TETTEKET ZESETSZT TETEMET AZ TEZTME KEZIT HESEZT 


2270 - Windows 2003 Server és Active Directory alapismeretek és 


két nap alatt megtudhatja mindazt, amit egyedül másfél év alatt lehet / 
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